1 2013-06-22 00:15:30 <warren> When bitcoin selects random peers to connect, it avoids peers in the same subnet, how large of a subnet?
2 2013-06-22 00:15:42 <warren> can't find where I saw that in docs earlier...
3 2013-06-22 01:02:47 <Luke-Jr> <.<
4 2013-06-22 01:02:47 <Luke-Jr> next year, we should do a release in February, and mine a commit hash starting with febNNNN
5 2013-06-22 01:04:35 <Luke-Jr> too bad hex can't do 'apr', or it'd make a nice April Fools' thing
6 2013-06-22 01:06:00 <shesek> according to https://en.bitcoin.it/wiki/Transactions#general_format_of_a_Bitcoin_transaction_.28inside_a_block.29 the version number should be 4 bytes, and the in count should be varint
7 2013-06-22 01:06:38 <shesek> but it seems like the version number is one byte, and the in count is 4 bytes
8 2013-06-22 01:06:55 <shesek> (transaction created with bitcoind begin with 0100000001)
9 2013-06-22 01:06:58 <shesek> is the wiki wrong?
10 2013-06-22 01:08:19 <shesek> looks like its reversed - the version number is varint (or just a uint8) and the in count is uint32
11 2013-06-22 01:08:24 <phantomcircuit> shesek, https://en.bitcoin.it/wiki/Protocol_specification#tx
12 2013-06-22 01:08:35 <gmaxwell> shesek: http://en.wikipedia.org/wiki/Endianness
13 2013-06-22 01:10:12 <shesek> phantomcircuit, it says the same as the Transactions page
14 2013-06-22 01:10:45 <shesek> gmaxwell, I know about endianness, how does it effect what I said?
15 2013-06-22 01:11:44 <gmaxwell> shesek: The version is little endian.
16 2013-06-22 01:11:44 <Luke-Jr> shesek: 01000000 01
17 2013-06-22 01:11:44 <shesek> oh
18 2013-06-22 01:11:46 <shesek> right. oops :)
19 2013-06-22 01:11:56 <shesek> ACTION facepalms
20 2013-06-22 01:12:33 <Luke-Jr> you're not the first
21 2013-06-22 01:52:42 <TheLordOfTime> if I want to create a bootstrap.dat from the blocks that i have in my bitcoin-qt directory, what do i need to do? (This is different than my "Can I directly copy blocks/* and chainstate/* from one client's data dir to another on a separate system" question)
22 2013-06-22 01:53:05 <TheLordOfTime> ACTION hasn't found a guide on how to create a bootstrap.dat yet
23 2013-06-22 01:57:08 <Luke-Jr> TheLordOfTime: cleanly, or ad-hoc?
24 2013-06-22 01:57:16 <Luke-Jr> ad-hoc, you can just concatenate the blk0*.dat files
25 2013-06-22 01:57:34 <TheLordOfTime> Luke-Jr: cleanly, preferably.
26 2013-06-22 01:57:52 <TheLordOfTime> but ad-hoc will work for local bootstraps.
27 2013-06-22 01:58:15 <TheLordOfTime> (the "concatenate the blk0*.dat" files method was one of the ones i found on the internet, but that was just in some mailing list)
28 2013-06-22 01:58:23 <Luke-Jr> TheLordOfTime: the simplest way that comes to mind would be to disconnect from the internet, bootstrap a new client from your own on localhost, and concat the new client's block files
29 2013-06-22 01:59:04 <Luke-Jr> I once wrote an overcomplex script to build it cleanly, but it was pre-LevelDB etc
30 2013-06-22 02:00:05 <TheLordOfTime> Luke-Jr: but bitcoin-qt can process an ad-hoc bootstrap.dat?
31 2013-06-22 02:00:19 <Luke-Jr> TheLordOfTime: yeah
32 2013-06-22 02:00:51 <TheLordOfTime> Luke-Jr: do you know how the (sorta old) bootstrap.dat that's been drifting around on the internet/bitcointalk was created per chance?
33 2013-06-22 02:01:04 <Luke-Jr> no
34 2013-06-22 02:01:07 <TheLordOfTime> (since people in -otc would LOVE to have an updated bootstrap.dat)
35 2013-06-22 02:01:14 <TheLordOfTime> OK well, i'll go poking around then
36 2013-06-22 02:01:18 <TheLordOfTime> we'll see what happens.
37 2013-06-22 02:01:30 <TheLordOfTime> ... after i reboot to purge the 1200MB in my swap o.O
38 2013-06-22 02:27:24 <TheLordOfTime> Luke-Jr: to test the bootstrap.dat and make sure it works, do i just run some runtime argument with bitcoin-qt to get it to load the bootstrap, or do i just dump bootstrap.dat into the data directory
39 2013-06-22 02:27:50 <Luke-Jr> the latter
40 2013-06-22 02:31:46 <shesek> anyone knows of a gui for multisig transactions?
41 2013-06-22 02:33:51 <[\\\\\\]> jgarzik, you about?
42 2013-06-22 04:38:24 <warren> Hmm. We can't make qt-win32-4.7.4-gitian.zip to be deterministic, and nothing obvious in bitcoin's git history that would help this.
43 2013-06-22 05:25:39 <Luke-Jr> kinlo: the authentication changes break passwordless auth - is there some reason you need to decode the utf8 bytes before it gets to the authentication modules? (passwordless has None for pw)
44 2013-06-22 07:54:03 <d_oilen> hi
45 2013-06-22 07:58:49 <d_oilen> after reading a lot of posts and a small part of the documentation i am still confused. I mean i have the powers to start developing an EFT-POS application and implement it in order to enpower small business like shops and other venues to trade BTC
46 2013-06-22 08:00:09 <d_oilen> my question is, is there a demand for such a terminal? i saw a lot of attempts to secure private keys via IC cards, Tokens, Paper, etc and some of them are successful
47 2013-06-22 08:00:14 <d_oilen> some of them not
48 2013-06-22 08:00:37 <d_oilen> i also seen the famous BitKiosk which has a lot of potential
49 2013-06-22 08:00:50 <d_oilen> but alot of regulation stay in it's path
50 2013-06-22 08:01:24 <d_oilen> i think the usage of an EFT-POS in a shop will not require so much regulation if at all
51 2013-06-22 08:01:51 <d_oilen> anybody?
52 2013-06-22 08:09:05 <sipa> d_oilen: unsure... how would your system work?
53 2013-06-22 08:09:52 <sipa> i have no idea about regulation though
54 2013-06-22 08:11:13 <d_oilen> 2 modules
55 2013-06-22 08:11:29 <d_oilen> 1: server connected to the p2p network readu to process transactions
56 2013-06-22 08:11:33 <d_oilen> ready
57 2013-06-22 08:11:53 <d_oilen> 2 EFT-POS with QRcode scanner, IC reader, etc
58 2013-06-22 08:12:30 <sipa> how do you pay?
59 2013-06-22 08:12:32 <d_oilen> the EFT will initiate a transaction to the server based on a key sighend bu the IC card let-s say for a certain amount of BTC
60 2013-06-22 08:12:56 <d_oilen> the server will then post the transaction to the network and wait for the confirmation
61 2013-06-22 08:13:09 <d_oilen> then it will relay the transaction reply back to the EFT
62 2013-06-22 08:13:13 <sipa> i may not understand what EFT means
63 2013-06-22 08:13:19 <d_oilen> EFT-POS
64 2013-06-22 08:13:37 <d_oilen> the terminal you put your card in when you pay at the supermarket in order to pay
65 2013-06-22 08:13:52 <sipa> ok, what card do you enter?
66 2013-06-22 08:14:58 <d_oilen> ChipCard like , secure ones which can hold securely the private key info
67 2013-06-22 08:15:08 <sipa> so a special card for this purpose?
68 2013-06-22 08:15:19 <d_oilen> hmmmm nope
69 2013-06-22 08:15:20 <sipa> who sells/creates these cards, and holds the BTC funds people pay with?
70 2013-06-22 08:15:24 <sipa> oh?
71 2013-06-22 08:15:36 <sipa> i couldn't use my regular bank card, could i?
72 2013-06-22 08:15:39 <d_oilen> we can build on existing QR code systems and ofcourse we can desigh a special one
73 2013-06-22 08:15:47 <d_oilen> no
74 2013-06-22 08:15:57 <d_oilen> this would be designed especially for BTC/LTC
75 2013-06-22 08:16:03 <d_oilen> no conversion
76 2013-06-22 08:16:06 <sipa> ok
77 2013-06-22 08:16:16 <d_oilen> between USD,AUD,or any other
78 2013-06-22 08:16:17 <sipa> so it is a special card designed to hold BTC funds
79 2013-06-22 08:16:27 <sipa> how does the card store these?
80 2013-06-22 08:16:45 <d_oilen> as a digital wallet
81 2013-06-22 08:16:54 <sipa> the funds are stored on the card itself?
82 2013-06-22 08:17:04 <d_oilen> can be
83 2013-06-22 08:17:11 <sipa> that's the important part
84 2013-06-22 08:17:21 <d_oilen> hmmm
85 2013-06-22 08:17:48 <d_oilen> the funds are consisting of your private key or i am wrong?
86 2013-06-22 08:18:12 <d_oilen> the card is limited in the amount of memory they can lock
87 2013-06-22 08:18:17 <sipa> a private key + an unspent transaction output crediting the associated address
88 2013-06-22 08:18:38 <d_oilen> total size?
89 2013-06-22 08:18:52 <sipa> 68 bytes
90 2013-06-22 08:18:57 <d_oilen> yep
91 2013-06-22 08:18:58 <sipa> (per coin)
92 2013-06-22 08:19:01 <d_oilen> it can be stored
93 2013-06-22 08:19:07 <sipa> yes, i know it can
94 2013-06-22 08:19:21 <sipa> where will you implement the wallet logic?
95 2013-06-22 08:19:32 <d_oilen> in the EFT-POS
96 2013-06-22 08:19:49 <d_oilen> card will be used fot sign purposes
97 2013-06-22 08:20:05 <d_oilen> since the private key once personalized cannot be read
98 2013-06-22 08:20:05 <sipa> so the EFT-POS can ask you "pay 0.01 BTC? enter code: ....", and in reality rob all coins?
99 2013-06-22 08:20:15 <d_oilen> nope
100 2013-06-22 08:20:19 <sipa> why not?
101 2013-06-22 08:20:56 <d_oilen> because the EFT application is locked and cannot be modified
102 2013-06-22 08:21:07 <sipa> ah, so you are relying on trusted hardware
103 2013-06-22 08:21:15 <sipa> then why have the keys in the card itself anyway?
104 2013-06-22 08:21:19 <d_oilen> you cannot install an application into an EFT without a proper certificate
105 2013-06-22 08:21:38 <d_oilen> because you require 2 sides of a transaction
106 2013-06-22 08:21:41 <sipa> i'd feel much more confortable with a system where that risk doesn't exist, like the trezor
107 2013-06-22 08:22:02 <sipa> and the entire wallet is managed by your own device
108 2013-06-22 08:22:10 <d_oilen> and how is that risk mitigated?
109 2013-06-22 08:22:22 <d_oilen> well that is the idea
110 2013-06-22 08:22:44 <sipa> apparently not, you are talking about only doing the signing in the card
111 2013-06-22 08:22:49 <d_oilen> you cannot rob my coins from my card because you cannot sign a transaction without a private key
112 2013-06-22 08:23:11 <d_oilen> without my private key
113 2013-06-22 08:23:12 <sipa> well if you rely on a trusted interface to the card, you can guarantee that for sure
114 2013-06-22 08:23:34 <d_oilen> ?
115 2013-06-22 08:23:40 <d_oilen> what do you mean?
116 2013-06-22 08:23:44 <sipa> but if i can create a device that looks like an EFT-POS, and asks the customer "pay 0.01? enter code: ...", and in reality sends a request to my card for 100 BTC
117 2013-06-22 08:23:55 <sipa> + the correct code
118 2013-06-22 08:23:59 <d_oilen> yes you can
119 2013-06-22 08:24:06 <sipa> that's the risk i'm talking about
120 2013-06-22 08:24:24 <sipa> and i prefer a system where the wallet is managed by your own device, instead of the merchant's
121 2013-06-22 08:24:33 <d_oilen> but it would not go into the network
122 2013-06-22 08:24:37 <sipa> heh, why not?
123 2013-06-22 08:24:45 <sipa> the card doesn't know the request was fake
124 2013-06-22 08:25:38 <d_oilen> hmm
125 2013-06-22 08:25:42 <d_oilen> let me see
126 2013-06-22 08:25:43 <sipa> the card can't even know the amount being paid, without it managing the wallet itself
127 2013-06-22 08:26:04 <d_oilen> the card is just an authentication token
128 2013-06-22 08:26:23 <sipa> yes, so the card can allow or not allow access to its funds
129 2013-06-22 08:26:25 <d_oilen> the amount is set by merchant
130 2013-06-22 08:26:32 <d_oilen> yes
131 2013-06-22 08:26:39 <d_oilen> you are forgetting one thing
132 2013-06-22 08:26:53 <d_oilen> you are doing business with a real merchant
133 2013-06-22 08:27:02 <d_oilen> you are not on an online business
134 2013-06-22 08:27:13 <d_oilen> so if the guy robs you
135 2013-06-22 08:27:27 <d_oilen> you know where to go to get your money back
136 2013-06-22 08:27:34 <sipa> you won't know your funds are stolen until you try to pay more with it later and there are insufficient funds
137 2013-06-22 08:27:54 <d_oilen> but still
138 2013-06-22 08:28:00 <d_oilen> the merchant is there
139 2013-06-22 08:28:10 <d_oilen> you can go and request your money
140 2013-06-22 08:28:13 <sipa> maybe he's in the bahama's by the time you find out?
141 2013-06-22 08:28:21 <sipa> your argument is that trust isn't necessary
142 2013-06-22 08:28:27 <sipa> maybe in some cases that is true
143 2013-06-22 08:28:40 <sipa> but if that's the case, why not use a traditional system without all the hassle?
144 2013-06-22 08:28:53 <d_oilen> well
145 2013-06-22 08:29:02 <d_oilen> that was the origin of my question
146 2013-06-22 08:29:15 <d_oilen> does this kind of system worh it?
147 2013-06-22 08:29:36 <sipa> maybe, i'm no business person, maybe it would work
148 2013-06-22 08:30:37 <sipa> but it sort of defeats the idea imho: bitcoin lets you be in control of your own money, and you go as far as putting the actual keys and coins in a card owner by the person... but then still need to rely on foolproof hardware to prevent theft?
149 2013-06-22 08:30:55 <sipa> if you go the road of giving people their own money, go all the way
150 2013-06-22 08:31:10 <d_oilen> like how?
151 2013-06-22 08:31:33 <sipa> have the device people own themself ask for confirmation
152 2013-06-22 08:31:43 <sipa> and do the authentication and constructing the transaction
153 2013-06-22 08:32:31 <sipa> i can go to a bitcoin store today (there are very few though :D), they show my a QR code with an address, i scan it with my android app, and it's paid within seconds
154 2013-06-22 08:32:41 <sipa> and there is no risk of the merchant robbing me at all
155 2013-06-22 08:32:49 <sipa> i don't need to trust his hardware
156 2013-06-22 08:33:08 <sipa> well, he can still not give you the goods of course
157 2013-06-22 08:33:21 <sipa> but i mean, there is no risk that he takes more money than you're asked
158 2013-06-22 08:34:10 <d_oilen> hmmm
159 2013-06-22 08:34:11 <swulf--> not giving you the goods = a problem for a court system to solve, not a payment processing/financial system
160 2013-06-22 08:34:18 <sipa> swulf--: indeed
161 2013-06-22 08:34:24 <sipa> i could also just punch him in the face
162 2013-06-22 08:34:29 <d_oilen> that was the response i was looking for
163 2013-06-22 08:34:38 <swulf--> sipa: then we'd have to design a police system too :(
164 2013-06-22 08:34:41 <d_oilen> there is no demand for such applications
165 2013-06-22 08:34:51 <sipa> d_oilen: oh, i haven't said anything about demand
166 2013-06-22 08:35:03 <sipa> d_oilen: there may well be people who'd like such a system
167 2013-06-22 08:35:10 <sipa> d_oilen: i'm biased as a bitcoin developer
168 2013-06-22 08:35:13 <d_oilen> well you just said that you would not trust an EFT=POS
169 2013-06-22 08:35:22 <sipa> no, i should you should not need to trust it
170 2013-06-22 08:35:35 <sipa> whether people would trust it, is something i can't answer
171 2013-06-22 08:35:40 <sipa> *i said
172 2013-06-22 08:36:41 <d_oilen> the basic idea was to help BTC go the distance into the merchant shops
173 2013-06-22 08:36:54 <d_oilen> most of the merchants are used to use now EFT-POS
174 2013-06-22 08:37:11 <sipa> well, i'm far from convinced Bitcoin is ready for that yet :)
175 2013-06-22 08:37:16 <sipa> but don't listen to me :p
176 2013-06-22 08:37:26 <d_oilen> so enabling them to operate with BTC almost like with a real card would benefit
177 2013-06-22 08:37:51 <sipa> that would by the way also make merchants completely responsible themself for handling security
178 2013-06-22 08:38:28 <sipa> people could try to double-spend etc
179 2013-06-22 08:38:49 <d_oilen> yes they could
180 2013-06-22 08:38:55 <d_oilen> but again
181 2013-06-22 08:39:10 <d_oilen> it is more like face to face trading
182 2013-06-22 08:39:22 <d_oilen> fraud will exist in any situation
183 2013-06-22 08:39:33 <sipa> except that a dollar bill i give you can't be taken back
184 2013-06-22 08:39:50 <sipa> and sure, fraud will exist in any system, and you need to deal with it
185 2013-06-22 08:40:10 <sipa> perhaps have sort of an insurance for merchants against double spending
186 2013-06-22 08:43:02 <d_oilen> i do not know the protocol in it's deepest intrinsecs but i think such a sytem can be devised to guard against double spending
187 2013-06-22 08:43:21 <d_oilen> without relying on other trusts
188 2013-06-22 08:43:30 <d_oilen> to counterfeit for bad merchants
189 2013-06-22 08:43:34 <sipa> that's even theoretically impossible, i think
190 2013-06-22 08:43:48 <d_oilen> i do not know
191 2013-06-22 08:43:59 <sipa> double spending is a problem because of the limited speed of light
192 2013-06-22 08:44:03 <d_oilen> but if as i understand all transactions are visible
193 2013-06-22 08:44:19 <sipa> you cannot be aware of another transaction spending the same coins, being created at the same time in another place
194 2013-06-22 08:44:36 <sipa> and only one of both can be valid, but neither has any reason to be more valid than the other
195 2013-06-22 08:44:57 <sipa> so you need a way to make that choice
196 2013-06-22 08:45:17 <sipa> the typical choice is a centralized clearinghouse, but that requires trust in the clearinghouse
197 2013-06-22 08:45:51 <sipa> bitcoin uses a voting mechanism called the blockchain, which only probabilistically converges (so you are never 100% sure)
198 2013-06-22 08:46:01 <d_oilen> no
199 2013-06-22 08:46:05 <d_oilen> no clearing house
200 2013-06-22 08:46:11 <d_oilen> it is against bitcoin
201 2013-06-22 08:46:11 <swulf--> well there's OT which is largely trustless, except the reliability part
202 2013-06-22 08:46:20 <sipa> d_oilen: of course
203 2013-06-22 08:46:31 <sipa> d_oilen: i'm just explaining two solutions to the double spending problem I know
204 2013-06-22 08:46:39 <d_oilen> well
205 2013-06-22 08:46:48 <sipa> but it's an inherent problem... you're always relying on something to make the choice
206 2013-06-22 08:46:50 <d_oilen> double spending occurs even with the current systems
207 2013-06-22 08:46:55 <sipa> of course
208 2013-06-22 08:47:01 <d_oilen> so that is " built in"
209 2013-06-22 08:47:09 <d_oilen> the merchant has a risk
210 2013-06-22 08:47:10 <sipa> doesn't mean we can't try to improve it
211 2013-06-22 08:47:32 <d_oilen> not without relinquishing control over some clearing house
212 2013-06-22 08:47:46 <d_oilen> which is not the intended behaviour
213 2013-06-22 08:49:13 <sipa> a clearing house doesn't necessarily mean full trust
214 2013-06-22 08:49:53 <d_oilen> brb
215 2013-06-22 08:49:54 <sipa> and doing all transactions including real-life payments on the blockchain is impossible (currently), imho
216 2013-06-22 08:50:27 <sipa> so if things scale up to that level, there will need to be some way of off-chain transactions anyway
217 2013-06-22 08:55:02 <d_oilen> maybe that is the route by using off-chained transactions
218 2013-06-22 08:55:14 <d_oilen> but they give less security
219 2013-06-22 08:58:25 <swulf--> sipa: what's wrong with OpenTransactions as a clearing house?
220 2013-06-22 08:59:20 <sipa> swulf--: nothing
221 2013-06-22 08:59:52 <sipa> well, it's not a clearing house - but it's a way of doing off-chain transactions
222 2013-06-22 08:59:54 <swulf--> i mean, nothing is perfect, but it sounds like OT would be great for instant bitcoin payments
223 2013-06-22 09:00:06 <sipa> that requires lower trust than a traditional bank
224 2013-06-22 09:00:06 <swulf--> can't it function as a clearing house?
225 2013-06-22 09:00:25 <sipa> well it operates on token, as far as i understand
226 2013-06-22 09:00:43 <sipa> you don't have the coins yourself, you have a token from the bank that you can trade
227 2013-06-22 09:00:51 <sipa> and the bank doesn't know who has which token
228 2013-06-22 09:00:52 <swulf--> "on token"? I suppose you have to trust the creditor
229 2013-06-22 09:01:00 <sipa> but the bank holds the actual BTC
230 2013-06-22 09:01:00 <swulf--> sure
231 2013-06-22 09:01:15 <sipa> (as far as i understand)
232 2013-06-22 09:01:39 <swulf--> related to the OT+Bitmessage exchage stuff, you could always use a voting pool of btc nodes to be the "bank"
233 2013-06-22 09:02:01 <sipa> sounds like ripple
234 2013-06-22 09:02:07 <swulf--> eh? nothing like ripple
235 2013-06-22 09:02:49 <d_oilen> well
236 2013-06-22 09:03:09 <sipa> swulf--: s/ripple/opencoin/
237 2013-06-22 09:03:42 <d_oilen> i left a message on the forum in Newbies section ( i am a new registered user) so if anyone is interested maybe we will discuss this furhter
238 2013-06-22 09:04:45 <d_oilen> but i will investigate a little more into how such a system can be put in actual function
239 2013-06-22 09:04:54 <d_oilen> i have some crypto cards available
240 2013-06-22 09:05:19 <d_oilen> and some EFT-terminals and i will try to put a demo up
241 2013-06-22 09:07:22 <swulf--> ah
242 2013-06-22 09:21:49 <warren> hm, did versions of bitcoin prior to addnode becoming RPC have any means to force a connection to a particular peer?
243 2013-06-22 09:24:25 <sipa> no
244 2013-06-22 09:24:46 <sipa> well, -connect and -addnode as command-line options have existed for a long time
245 2013-06-22 09:25:05 <warren> yeah, -addnode exists, but it seems to not actually connect to the specified node
246 2013-06-22 09:25:15 <warren> -connect does work
247 2013-06-22 09:28:30 <warren> oh.... it is working, except for localhost where it doesn't.
248 2013-06-22 10:09:22 <kinlo> Luke-Jr: stratum decodes sooner in the flow, and has the username/password as string, utf-8 decoded. The http doesn't do that so at that point you have binary data. To make sure the password module can work with uniform values, I decode....
249 2013-06-22 10:17:12 <warren> sipa: ah.... addnode= it the .conf file doesn't work, only -addnode= does
250 2013-06-22 10:17:21 <warren> this rather sucks
251 2013-06-22 10:18:43 <sipa> warren: that makes no sense
252 2013-06-22 10:18:58 <sipa> command-line argument are treated exactly the same as config file lines
253 2013-06-22 10:19:25 <warren> I might just be very tired
254 2013-06-22 10:43:49 <Luke-Jr> kinlo: hmm, maybe in that case I should do the conversion earlier on, with a check that it's not None first
255 2013-06-22 10:45:49 <kinlo> Luke-Jr: kinda surprises me tough that someone would put binary data inside their username/pasword
256 2013-06-22 10:46:37 <Luke-Jr> kinlo: probably won't happen
257 2013-06-22 10:46:40 <Luke-Jr> kinlo: the problem is password=None
258 2013-06-22 10:46:46 <Luke-Jr> None doesn't decode.
259 2013-06-22 11:09:16 <kinlo> Luke-Jr: perhaps a small if/then to replace None with "" would solve the problem
260 2013-06-22 11:10:26 <Luke-Jr> kinlo: but None is distinct from ""
261 2013-06-22 11:11:05 <kinlo> Luke-Jr: true, but in terms of password validation, it is ok to interpret that as the empty string imho
262 2013-06-22 11:12:19 <kinlo> Luke-Jr: otherwise you need to pass None as value to the password modules and let them figure it out, altough I prefer to keep the complexity in the password modules as low as possible to make it easy for the password module writers
263 2013-06-22 11:14:15 <Luke-Jr> kinlo: well, that's kinda independent of this issue IMO ; right now it never works at all
264 2013-06-22 11:14:21 <Luke-Jr> kinlo: does this work for you? http://codepad.org/piBJ9XBD
265 2013-06-22 11:55:48 <Mr_Cloud> Hey everyone
266 2013-06-22 12:05:21 <Mr_Cloud> How can we explore the blocks we downloaded from our HDD as opposed to block explorer, blockchain etc?
267 2013-06-22 12:05:41 <Mr_Cloud> Are the blocks encrypted? Or compressed? Or.. Both?
268 2013-06-22 12:06:08 <Mr_Cloud> *the blocks we downloaded ON our HDD
269 2013-06-22 12:06:43 <sipa> Mr_Cloud: you can use the getblockhash, getblock and getrawtransaction RPC calls
270 2013-06-22 12:07:18 <sipa> you need to enable the transaction index (txindex=1 in the config file, and potentially rebuild your database to have it) before getrawtransaction works
271 2013-06-22 12:07:55 <sipa> they're stored in network format in the blocks/blk*.dat files, concatenated with 4 magic bytes and 4 length bytes before each block
272 2013-06-22 12:07:56 <Mr_Cloud> Will the exe automatically rebuild the db for me if I set the txindex param?
273 2013-06-22 12:08:01 <sipa> no
274 2013-06-22 12:08:08 <sipa> you'll need to start with -reindex once
275 2013-06-22 12:08:24 <sipa> it's around a GB extra database
276 2013-06-22 12:10:47 <Mr_Cloud> Ok, reindexing now
277 2013-06-22 12:21:51 <jaromil> OT: yesterday at the insitute of social sciences in Den Haag there was the second Complementary Currency conference with several interesting panels and big shots in social banking and such. we were a few Bitcoin aware people and BTC was debated as well in policy making panels - shortly put the picture that came out is not all grim and negative i'd say. but ok, not sure how many here are interested in EU policy makers opinions :^) all in all was a good gig.
278 2013-06-22 12:24:00 <sipa> jaromil: good to hear!
279 2013-06-22 12:25:15 <Subo1978_> hi : when wuld issue #2773
280 2013-06-22 12:25:15 <Subo1978_> Pull request 2763 / Problems bitcoin over Tor be solved ?
281 2013-06-22 12:31:09 <sipa> Subo1978_: looks to me like there's just some non-compliant node out there that doesn't understand that extra bool flag
282 2013-06-22 12:31:16 <sipa> Subo1978_: and is trying to connect to you through tor
283 2013-06-22 12:35:15 <Mr_Cloud> Taking forever to reindex, ffff????????????-
284 2013-06-22 12:35:29 <sipa> increasing the dbcache helps a lot
285 2013-06-22 12:35:36 <sipa> -dbcache=1000 if you want to give it anything GB
286 2013-06-22 12:35:54 <sipa> you can quit, and it'll continue reindexing next time
287 2013-06-22 12:35:57 <Mr_Cloud> Can I stick that in the conf file?
288 2013-06-22 12:36:00 <sipa> yes
289 2013-06-22 12:36:03 <sipa> dbcache=1000
290 2013-06-22 12:36:11 <sipa> or any number you like
291 2013-06-22 12:36:17 <sipa> more than 1000 doesn't help much though
292 2013-06-22 12:37:01 <Mr_Cloud> Thanks sipa. Says it's rescanning now on the splash screen
293 2013-06-22 12:37:19 <sipa> which version is that?
294 2013-06-22 12:37:24 <Mr_Cloud> I think something really usefu-
295 2013-06-22 12:37:25 <Mr_Cloud> Um
296 2013-06-22 12:37:35 <Mr_Cloud> 0.8.1
297 2013-06-22 12:37:38 <Mr_Cloud> Beta
298 2013-06-22 12:37:46 <sipa> right, it had that bug still
299 2013-06-22 12:37:49 <sipa> try 0.8.2
300 2013-06-22 12:37:54 <sipa> it doesn't rescan that often
301 2013-06-22 12:38:36 <Mr_Cloud> Ok, downloading now lol
302 2013-06-22 12:39:25 <Mr_Cloud> I think something really useful would be the implementation of QSettings for pos.x() and pos.y() of the main window
303 2013-06-22 12:39:55 <Mr_Cloud> As well as the size. That way it remembers which screen you put it on
304 2013-06-22 12:44:15 <warren> i'm looking foward to the wallet birthday thing being standard
305 2013-06-22 12:54:44 <Mr_Cloud> People goin' crazy over litecoin ever since yesterday
306 2013-06-22 13:00:53 <Mr_Cloud> sipa I'm trying to to an RPC command via curl, but it "could not resolve" stuff
307 2013-06-22 13:01:14 <Mr_Cloud> I have bitcoin-qt.exe -server and it's currently indexing the blocks
308 2013-06-22 13:01:25 <Mr_Cloud> *Re-indexing, rather
309 2013-06-22 13:01:59 <Mr_Cloud> And I tried querying it using the https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29 default curl command
310 2013-06-22 13:02:43 <Mr_Cloud> Any ideas?
311 2013-06-22 13:08:26 <sipa> can you be more specific?
312 2013-06-22 13:08:36 <sipa> which command are you executing, what exact error do you get?
313 2013-06-22 13:12:11 <Mr_Cloud> One moment
314 2013-06-22 13:12:46 <Mr_Cloud> curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
315 2013-06-22 13:13:31 <sipa> looks good
316 2013-06-22 13:13:45 <sipa> is 'user' your username?
317 2013-06-22 13:14:32 <Mr_Cloud> No, I changed it (and the command I'm sending) accordingly
318 2013-06-22 13:14:43 <Mr_Cloud> It asks for password and then:
319 2013-06-22 13:14:53 <Mr_Cloud> curl: (6) Could not resolve host: 1.0,
320 2013-06-22 13:14:54 <Mr_Cloud> curl: (6) Could not resolve host: id
321 2013-06-22 13:14:55 <Mr_Cloud> curl: (6) Could not resolve host: method
322 2013-06-22 13:14:57 <Mr_Cloud> curl: (6) Could not resolve host: getinfo,
323 2013-06-22 13:14:59 <Mr_Cloud> curl: (6) Could not resolve host: params
324 2013-06-22 13:15:00 <Mr_Cloud> curl: (3) [globbing] illegal character in range specification at pos 2
325 2013-06-22 13:15:01 <Mr_Cloud> curl: (3) [globbing] unmatched close brace/bracket at pos 1
326 2013-06-22 13:15:03 <Mr_Cloud> curl: (6) Could not resolve host: text
327 2013-06-22 13:15:05 <Mr_Cloud> curl: (7) Failed connect to 127.0.0.1:8332; No error
328 2013-06-22 13:15:06 <Mr_Cloud> Sorry about spam
329 2013-06-22 13:16:31 <sipa> maybe windows's shell needs different escaping
330 2013-06-22 13:16:42 <sipa> it seems to not understand the ' characters
331 2013-06-22 13:16:51 <sipa> can't help you there, though
332 2013-06-22 13:17:31 <Mr_Cloud> Sheeeeeiiiiiiiiittt
333 2013-06-22 13:17:33 <Mr_Cloud> Ok thanks
334 2013-06-22 13:21:56 <Mr_Cloud> Ok, fixed the syntax error
335 2013-06-22 13:22:18 <Mr_Cloud> The translation of " and ' is \\" and " respectively on win7 x64
336 2013-06-22 13:22:25 <Mr_Cloud> According to http://stackoverflow.com/questions/11834238/curl-post-command-line-on-windows-restful-service
337 2013-06-22 13:22:51 <Mr_Cloud> But now, I get failed to connect to 127.0.0.1:8332
338 2013-06-22 13:25:21 <Mr_Cloud> Holy shit, bitcoin-qt is owning my CPU
339 2013-06-22 13:25:36 <sipa> yes, it's validating the chain
340 2013-06-22 13:25:46 <sipa> at full speed, since it's not limited by the network to fetch blocks
341 2013-06-22 13:25:54 <Mr_Cloud> Almost 1.1gig of rams as well
342 2013-06-22 13:26:09 <sipa> sounds good
343 2013-06-22 13:26:17 <sipa> at least if you gave it that much
344 2013-06-22 13:26:25 <Mr_Cloud> I got to 11 weeks behind
345 2013-06-22 13:27:30 <Mr_Cloud> Could the fact that it's reindexing get in the way of accessing things via RPC?
346 2013-06-22 13:27:49 <Mr_Cloud> i.e. could that be the reason why I couldn't connec to localhost using curl?
347 2013-06-22 13:28:02 <sipa> no
348 2013-06-22 13:28:18 <sipa> it may explain why it would take a (really) long time to respond
349 2013-06-22 13:28:22 <sipa> but not why it couldn't connect
350 2013-06-22 13:28:51 <Mr_Cloud> Takes about 1-2s to come up with failed to connect message after inputting password
351 2013-06-22 13:29:15 <sipa> well let it reindex first
352 2013-06-22 13:29:20 <Mr_Cloud> Will do
353 2013-06-22 13:29:20 <sipa> but i don't think it's related
354 2013-06-22 13:32:33 <i2pRelay> <toran@i2p> hello?
355 2013-06-22 13:34:31 <i2pRelay> <toran@i2p> i have a question about early adoption?
356 2013-06-22 13:35:21 <sipa> ok?
357 2013-06-22 13:36:51 <i2pRelay> <toran@i2p> why were the original developers nervous about too many people jumping on bitcoin at first?
358 2013-06-22 13:37:11 <i2pRelay> <toran@i2p> like how wikileaks starting taking bitcoin donations but satoshi asked them not to
359 2013-06-22 13:39:25 <buZz> i2pRelay: eh, satoshi didnt ask them
360 2013-06-22 13:39:48 <buZz> satoshi hasnt said/released _anything_ since the code
361 2013-06-22 13:39:56 <i2pRelay> <toran@i2p> then who did?
362 2013-06-22 13:40:08 <i2pRelay> <toran@i2p> no in the very early days
363 2013-06-22 13:40:10 <i2pRelay> <toran@i2p> before he left
364 2013-06-22 13:40:18 <buZz> he left after the code went public
365 2013-06-22 13:40:22 <sipa> satoshi did ask wikileaks not to accept bitcoins
366 2013-06-22 13:40:27 <sipa> buZz: eh, no
367 2013-06-22 13:40:28 <buZz> oh :O
368 2013-06-22 13:40:38 <buZz> ACTION was misinformed
369 2013-06-22 13:40:38 <sipa> buZz: the code was published in januari 2009
370 2013-06-22 13:40:52 <sipa> satoshi kept developing it until the end of 2010
371 2013-06-22 13:40:59 <i2pRelay> <toran@i2p> @sipa so why did he do that?
372 2013-06-22 13:41:43 <sipa> toran: i never communicated with satoshi, but my guess is he didn't like it being associated with politically controverse
373 2013-06-22 13:42:18 <i2pRelay> <toran@i2p> oh i thought it had something to do with the curreny getting too much attention
374 2013-06-22 13:42:26 <sipa> yes, that too
375 2013-06-22 13:42:33 <sipa> he didn't seem to like attention at all
376 2013-06-22 13:42:43 <i2pRelay> <toran@i2p> like it'd be bad if it got too many users at first
377 2013-06-22 13:43:07 <sipa> i sort-of agree with that, actually
378 2013-06-22 13:45:00 <i2pRelay> <toran@i2p> what was wrong with too much attention?
379 2013-06-22 13:46:11 <sipa> (my opinion; not necessarily his reason) increased popularity makes development much harder
380 2013-06-22 13:46:37 <sipa> as you suddenly have to care about security, and stability, and not experimenting too much
381 2013-06-22 13:54:04 <shesek> I wonder if he's still here, under another nickname
382 2013-06-22 13:54:25 <shesek> must be hard to abandon your project like that and watch it grow as a bystander
383 2013-06-22 13:57:04 <i2pRelay> <toran@i2p> can anyone answer my question?
384 2013-06-22 13:59:07 <sipa> which question?
385 2013-06-22 13:59:18 <sipa> 17:42:16 < i2pRelay> <toran@i2p> what was wrong with too much attention?
386 2013-06-22 13:59:24 <sipa> 17:43:27 < sipa> (my opinion; not necessarily his reason) increased popularity makes development much harder
387 2013-06-22 13:59:30 <sipa> 17:43:54 < sipa> as you suddenly have to care about security, and stability, and not experimenting too much
388 2013-06-22 13:59:37 <i2pRelay> <toran@i2p> what is dangerous about a new currency or social network from having too many new users
389 2013-06-22 14:00:06 <i2pRelay> <toran@i2p> okay thank you
390 2013-06-22 14:00:30 <Vinnie_win> sipa: done
391 2013-06-22 14:01:39 <sipa> Vinnie_win: is there a way to get the individual leveldb commits map to individual bitcoin commits?
392 2013-06-22 14:01:56 <Vinnie_win> I'm not sure I follow...what do you mean by "individual bitcoin commits?"
393 2013-06-22 14:02:08 <Vinnie_win> sipa: You want to see the commit log of the subtree?
394 2013-06-22 14:02:25 <sipa> so that we'd get a pull request with commits "Rate limit compactions with a 25ms pause after each complete file.", for example
395 2013-06-22 14:03:02 <Vinnie_win> sipa: Hmm...Yes, that is possible. I can leave out the "--squash" option. But if I do that, then you will have the *entire* commit log of leveldb inserted into the commit log of bitcoin. I will prepare another branch so you can see what it would look like, 1 sec.
396 2013-06-22 14:03:38 <sipa> Vinnie_win: only of what changed since the previous 'sync' with the leveldb repo, no?
397 2013-06-22 14:04:04 <Vinnie_win> sipa: Yes that would be true, but only after the first non-squash commit.
398 2013-06-22 14:04:11 <sipa> hmm
399 2013-06-22 14:04:32 <Vinnie_win> You can always split the changes to see the commit log if you'd like. And I believe that the individual commits are in the body of the merge commit, no?
400 2013-06-22 14:05:27 <Vinnie_win> Hmm...seems the new branch failed the build test...
401 2013-06-22 14:05:41 <sipa> head is currently broken
402 2013-06-22 14:05:48 <sipa> (well, not broken, but the tests are)
403 2013-06-22 14:06:52 <Vinnie_win> sipa: If you look at the message for commit 109b32b296 you can see the individual commit messages in the body of the squash commit.
404 2013-06-22 14:07:33 <Vinnie_win> sipa: http://i.imgur.com/OqBsmtf.png
405 2013-06-22 14:07:49 <sipa> sure
406 2013-06-22 14:08:11 <sipa> but unless you know what repository those changes live in, you can't actually see them
407 2013-06-22 14:08:16 <sipa> only their descriptions
408 2013-06-22 14:08:26 <sipa> and the commit id's don't make sense inside the bitcoin repo
409 2013-06-22 14:08:38 <Vinnie_win> You can always split them to another branch in bitcoin, like this:
410 2013-06-22 14:08:46 <Vinnie_win> git subtree split -P src/leveldb -b leveldb
411 2013-06-22 14:09:19 <Vinnie_win> This will create a new branch called "leveldb" inside the bitcoin repo which comes from the subtree. The result will look identical to this:
412 2013-06-22 14:09:20 <Vinnie_win> https://github.com/vinniefalco/LevelDB/tree/ripple-fork
413 2013-06-22 14:09:55 <sipa> i'll comment on the repo and wait for some other developers to comment
414 2013-06-22 14:10:41 <boycey> Hi, everyone
415 2013-06-22 14:11:23 <boycey> Can somebody explain to me, the meaning of a 'meta-chain' in the new bitcoin scalability engineering project?
416 2013-06-22 14:11:31 <Vinnie_win> sipa: https://github.com/vinniefalco/bitcoin/tree/leveldb-full-log This is what the bitcoin commit log would look like with the entire leveldb commit log added. If this is what you want, I can prepare another pull request.
417 2013-06-22 14:11:59 <sipa> boycey: link?
418 2013-06-22 14:12:57 <boycey> sipa: http://bit.ly/12hy5ZD
419 2013-06-22 14:13:22 <boycey> "The client downloads the ???longest??? (most work) meta-chain"...
420 2013-06-22 14:13:47 <boycey> Just trying to figure out how it works ;)
421 2013-06-22 14:14:20 <sipa> unsure why they need a separate chain
422 2013-06-22 14:14:38 <sipa> each block should just commit to the utxo state
423 2013-06-22 14:15:42 <sipa> maybe maaku can comment?
424 2013-06-22 14:16:45 <boycey> Isn't the idea that the separate chain is smaller file size?
425 2013-06-22 14:17:01 <sipa> it will be, but that's not relevant
426 2013-06-22 14:17:09 <sipa> you need the bitcoin chain too
427 2013-06-22 14:17:16 <sipa> (not the blocks, just the headers)
428 2013-06-22 14:19:12 <boycey> Mmm
429 2013-06-22 14:21:11 <sipa> Vinnie_win: seems leveldb 1.12 is out already
430 2013-06-22 14:22:26 <sipa> Vinnie_win: where does that rate-limit change come from?
431 2013-06-22 14:23:13 <Vinnie_win> sipa: the rate limit comes from Ripple
432 2013-06-22 14:23:30 <sipa> can i read about the issue it solves somewhere?
433 2013-06-22 14:23:41 <Vinnie_win> I don't think so, it was a David Schwartz change
434 2013-06-22 14:24:08 <sipa> i'd still like to know why it's there :)
435 2013-06-22 14:24:17 <Vinnie_win> I believe it was to specifically address a problem found in the rippled server. Truth be told, we've encountered some issues with LevelDB. It's not the perfect hash store we thought it was.
436 2013-06-22 14:24:29 <Vinnie_win> I will ping him and see if he'll shed some light
437 2013-06-22 14:24:47 <sipa> it's by no means a hashtable
438 2013-06-22 14:24:58 <sipa> it's a key-value store with atomic bulk updates
439 2013-06-22 14:25:09 <Vinnie_win> yeah. well thats what I meant
440 2013-06-22 14:25:29 <sipa> and we've seen more problems than we'd expect too, but all of them are unexplained corruptions that we can't reproduce...
441 2013-06-22 14:26:52 <Vinnie_win> sounds about right
442 2013-06-22 14:27:27 <sipa> i mean, i myself have never even seen one, except when i was literally writing random data in the sst files while syncing
443 2013-06-22 14:27:46 <sipa> but others report quite frequent corruptions sometimes
444 2013-06-22 14:28:11 <sipa> and it seems strange to ascribe it all to hardware errors
445 2013-06-22 14:31:37 <Vinnie_win> Now that I've had a chance to look at the leveldb repo it doesn't seem up to the quality we expect from Google.
446 2013-06-22 14:31:55 <Vinnie_win> Anyway did you see the other branch I prepared that has the full commit log?
447 2013-06-22 14:32:06 <sipa> yes, but that's certainly not what i mean
448 2013-06-22 14:32:16 <Vinnie_win> What did you mean? All the commits are there
449 2013-06-22 14:32:39 <Mr_Cloud> Hok I'm out, later guys
450 2013-06-22 14:34:22 <sipa> Vinnie_win: i just meant the changes that are applied now
451 2013-06-22 14:34:26 <sipa> Vinnie_win: not the entire history
452 2013-06-22 14:34:33 <sipa> but perhaps that's a weird/hard request
453 2013-06-22 14:34:46 <Vinnie_win> sipa: Well, incremental updates will be possible, but first there needs to be a non-squash commit like in the branch I worked up for you.
454 2013-06-22 14:35:01 <Vinnie_win> sipa: in other words, if you accept the other branch then future updates to leveldb will have incremental commits in the log.
455 2013-06-22 14:35:40 <sipa> ok
456 2013-06-22 14:36:11 <sipa> we'll see what others think
457 2013-06-22 14:36:33 <setkeh> 20000 * 2**32 / 10**9 / 60 / 60.0 << How would one do this in decimal
458 2013-06-22 14:36:38 <Vinnie_win> do you want me to work on 1.12 updating?
459 2013-06-22 14:36:57 <sipa> ;;calc 20000 * 2**32 / 10**9 / 60 / 60.0
460 2013-06-22 14:36:58 <altgribble> 23.8609294222
461 2013-06-22 14:37:16 <Vinnie_win> sipa: 1.12 "Non functional changes"... to Authors, and LICENSE
462 2013-06-22 14:37:24 <sipa> Vinnie_win: yes, but 1.11 does have changes
463 2013-06-22 14:37:39 <Vinnie_win> sipa: I'll work on that today
464 2013-06-22 14:37:42 <setkeh> i know that works but if you put a decimal in for the hashrate instead of 10**9 it gives a different number
465 2013-06-22 14:38:00 <sipa> setkeh: ?
466 2013-06-22 14:38:30 <setkeh> ;;calc 20000 * 2**32 / 1000 / 60 / 60.0
467 2013-06-22 14:38:31 <altgribble> 23860929.4222
468 2013-06-22 14:38:34 <setkeh> see
469 2013-06-22 14:38:46 <sipa> eh, duh?
470 2013-06-22 14:38:47 <setkeh> acording to the wiki 10**9 is 1GH
471 2013-06-22 14:38:52 <sipa> yes
472 2013-06-22 14:38:59 <sipa> 10^9 = 1 billion
473 2013-06-22 14:39:18 <sipa> Vinnie_win: cool!
474 2013-06-22 14:39:24 <setkeh> aha
475 2013-06-22 14:39:28 <setkeh> now i get it
476 2013-06-22 14:39:43 <sipa> setkeh: 10**9 just means "10 to the power of 9", i.e. a 1 with 9 zeroes
477 2013-06-22 14:42:00 <setkeh> sipa: so say i have a HR of 3.94GH/s how do i convert that into the same notation ??
478 2013-06-22 14:42:12 <sipa> 3.94 * 10**9 ?
479 2013-06-22 14:42:39 <sipa> you can also just use 3940000000
480 2013-06-22 14:43:40 <setkeh> >>> print float(20000 * 2**32 / 10000000000 / 60)
481 2013-06-22 14:43:41 <setkeh> 143.0
482 2013-06-22 14:44:00 <setkeh> >>> print float(20000 * 2**32 / 10**9 / 60)
483 2013-06-22 14:44:02 <setkeh> 1431.0
484 2013-06-22 14:44:26 <setkeh> is what i ment about different output
485 2013-06-22 14:44:28 <sipa> 10000000000 = 1 with 10 zeroes = 10 billion
486 2013-06-22 14:44:46 <sipa> 10**9 is a 1 with 9 zeroes = 1 billion
487 2013-06-22 14:44:57 <setkeh> ahh
488 2013-06-22 14:45:08 <setkeh> derp
489 2013-06-22 14:45:09 <sipa> have you ever used a calculator?
490 2013-06-22 14:45:34 <setkeh> not really i was never allowed too :P
491 2013-06-22 14:51:22 <setkeh> so if 1 GH/s is 10**9 is 1 MH/s 10**6 (last stupif question for the night i promise XD)
492 2013-06-22 14:51:29 <sipa> yes
493 2013-06-22 14:51:47 <setkeh> badass thanks
494 2013-06-22 14:51:50 <sipa> https://en.wikipedia.org/wiki/Metric_prefix
495 2013-06-22 14:51:54 <sipa> G = 1000000000
496 2013-06-22 14:51:56 <sipa> M = 1000000
497 2013-06-22 14:52:40 <setkeh> that would have save us both some time had it showed up in google when i asked XD
498 2013-06-22 14:54:55 <Diablo-D3> k = thousand, m = million, g = billion, t = trillion
499 2013-06-22 14:55:11 <Luke-Jr> m = thousandTH
500 2013-06-22 14:55:15 <sipa> m = 1/1000, g = gravity constant, t = tonne
501 2013-06-22 14:55:23 <Luke-Jr> ^ :p
502 2013-06-22 14:55:30 <Diablo-D3> hurrrr
503 2013-06-22 14:55:45 <Diablo-D3> I do not use capitalized metric prefixes when in this context
504 2013-06-22 14:56:08 <sipa> well, prefixes have their own namespace
505 2013-06-22 14:56:19 <sipa> so how do you differentiate between milli and mega?
506 2013-06-22 14:56:44 <sipa> surely there are devices that only do one millihash/second :p
507 2013-06-22 14:57:40 <Luke-Jr> ??? = 2???4, ?? = 2???(4*2), ??? = 2???(4*3), ??? = 2???(4*4)
508 2013-06-22 17:01:21 <Vinnie_win> sipa: I've cherry picked the commits for LevelDB 1.11 and 1.12, do you want me to update the pull request?
509 2013-06-22 17:05:52 <sipa> Vinnie_win: sure
510 2013-06-22 17:10:43 <devrandom> warren: did you track down the qt-win32 determinism issue?
511 2013-06-22 17:11:12 <Vinnie_win> sipa: done!
512 2013-06-22 17:11:35 <xulf> what's going on bitcoin dev
513 2013-06-22 17:11:47 <xulf> Are you having a good day? tell me what the weather is like
514 2013-06-22 17:12:49 <xulf> Are you a robot?
515 2013-06-22 17:23:23 <setkeh> ok im confused again
516 2013-06-22 17:23:57 <setkeh> i have s = ServiceProxy(connectdeetails)
517 2013-06-22 17:24:37 <setkeh> but when i do s.getinfo("blocks") bitcoin rpc spits out an error
518 2013-06-22 17:24:45 <setkeh> same with getmininginfor
519 2013-06-22 17:24:49 <setkeh> info*
520 2013-06-22 17:25:21 <setkeh> but if i do s.getbalance("Master Wallet") works ok
521 2013-06-22 17:25:41 <setkeh> any idea's ??
522 2013-06-22 17:28:02 <sipa> getinfo doesn't take any argument
523 2013-06-22 17:30:11 <sipa> just do s.getinfo()
524 2013-06-22 17:30:41 <setkeh> that works but i only want the blocks number how can i just get that ??
525 2013-06-22 17:31:04 <sipa> depends on the programming language
526 2013-06-22 17:31:10 <setkeh> Python
527 2013-06-22 17:31:24 <sipa> i expect something like s.getinfo()['blocks'] then
528 2013-06-22 17:31:39 <setkeh> ill give it a whirl ty
529 2013-06-22 17:32:42 <setkeh> sipa: perfect thanks again bud :D
530 2013-06-22 17:43:02 <setkeh> ;;blocks
531 2013-06-22 17:43:04 <altgribble> 242828
532 2013-06-22 17:43:30 <altgribble> 233445063711462112
533 2013-06-22 17:43:30 <setkeh> ;;calc 242828/144*19339258.27239 * 2**32 / 600
534 2013-06-22 17:44:40 <altgribble> 233445063711462110272960856064
535 2013-06-22 17:44:40 <setkeh> ;;calc 242828/144*19339258.27239 * 2**32 * 10**12 / 600
536 2013-06-22 17:44:51 <setkeh> oops
537 2013-06-22 18:11:17 <BCB> does anyone know if there was a write up online anywere on what actually happened in bitcoin-dev during the recent blockchain fork?
538 2013-06-22 18:12:44 <setkeh> sipa: why does D * 2**32 / 600 (for calculating network hashrat according to the wiki) give my a number thats massive and wrong ??
539 2013-06-22 18:14:14 <michagogo> BCB: There's a link to logs in the topic, I think
540 2013-06-22 18:15:40 <michagogo> BCB: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 and http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12
541 2013-06-22 18:16:26 <sipa> ;;diff
542 2013-06-22 18:16:27 <altgribble> 1.933925827238668E7
543 2013-06-22 18:16:47 <sipa> ;calc 19339258 * 2**32 / 600
544 2013-06-22 18:16:54 <sipa> ;;calc 19339258 * 2**32 / 600
545 2013-06-22 18:16:55 <altgribble> 1.38435801065e+14
546 2013-06-22 18:17:00 <michagogo> 23:11\tthermoman\tanyone help?
547 2013-06-22 18:17:00 <michagogo> Looks to have started with 23:11\tthermoman\ti'm getting invalid chain and "no available lock entries" in db.log
548 2013-06-22 18:17:20 <sipa> michagogo: channel?
549 2013-06-22 18:17:33 <michagogo> sipa: #bitcoin-dev
550 2013-06-22 18:17:48 <sipa> ah
551 2013-06-22 18:18:03 <sipa> i was wondering whether another fork had finally happened :D
552 2013-06-22 18:18:04 <denisx> isn't 0xffff0000 more accurate then 2**32?
553 2013-06-22 18:18:09 <sipa> denisx: indeed
554 2013-06-22 18:18:15 <BCB> michagogo, thx. in the recent online depate the guy was using the fork as a serious flaw in bitcoin however I see the story of how the fork problem was solved as an amazing example of the collective effort of the technology.
555 2013-06-22 18:18:19 <sipa> setkeh: looks correct to me
556 2013-06-22 18:18:43 <sipa> setkeh: 1.38*10^14 hashes/s is 138TH/s
557 2013-06-22 18:19:22 <setkeh> ahh everywhere i looked was saying 198TH/s
558 2013-06-22 18:19:44 <sipa> well the difficulty doesn't match the hashrate perfectly
559 2013-06-22 18:19:50 <sipa> see http://bitcoin.sipa.be
560 2013-06-22 18:19:51 <BCB> michagogo, thx. Do you know if a summery article was ever written about it?
561 2013-06-22 18:20:16 <michagogo> BCB: About the discussion? Not AFAIK.
562 2013-06-22 18:20:20 <sipa> BCB: http://bitcoinmagazine.com/bitcoin-network-shaken-by-blockchain-fork/ ?
563 2013-06-22 18:20:22 <michagogo> There's BIP50
564 2013-06-22 18:20:29 <michagogo> Ah, okay
565 2013-06-22 18:20:33 <michagogo> maybe what sipa said
566 2013-06-22 18:20:38 <setkeh> sipa: oh yeah i knew that i just figured they wouldent be that different if its the same equasion :P
567 2013-06-22 18:21:19 <sipa> ;;diff
568 2013-06-22 18:21:20 <altgribble> 1.933925827238668E7
569 2013-06-22 18:22:02 <BCB> sipa, thx
570 2013-06-22 18:22:10 <sipa> ;;calc 19339258 * 2**48 / 65535 / 600
571 2013-06-22 18:22:11 <altgribble> 1.3843791346e+14
572 2013-06-22 18:22:30 <BCB> i don't see Gavin here but does anyone know if there is a link to a video of his cia talk
573 2013-06-22 18:22:35 <sipa> setkeh: see http://bitcoin.sipa.be/speed-large-lin.png
574 2013-06-22 18:22:41 <sipa> BCB: i don't think that's public :D
575 2013-06-22 18:22:58 <BCB> sipa, I though I saw a practice version of it public
576 2013-06-22 18:23:06 <sipa> oh
577 2013-06-22 18:23:24 <setkeh> ahh i see
578 2013-06-22 18:26:04 <Shockzz_> But that's only a practice version.
579 2013-06-22 18:26:39 <BCB> Shockzz_, still the slides are public
580 2013-06-22 18:28:39 <Shockzz__> Yeah, that screwed up bad.
581 2013-06-22 18:46:12 <Subo1978> sipa:
582 2013-06-22 18:46:46 <Subo1978> sipa: i solved the tor problem:
583 2013-06-22 18:47:45 <Subo1978> sipa: i have set the -discover parameter. after remove it all is ok.
584 2013-06-22 18:48:20 <sipa> that doesn't make any sense
585 2013-06-22 18:48:38 <sipa> at least not if the problem was in fact caused by the extra bool in the version message
586 2013-06-22 18:49:45 <Subo1978> sure? i testet it. with this parameter = Problem, without = ok. like a switch
587 2013-06-22 18:50:17 <Subo1978> befor the Pull the parameter dosnt make problems with tor.
588 2013-06-22 18:50:32 <Subo1978> if i remove the bool the parameter makes no sende
589 2013-06-22 18:50:51 <Subo1978> s/sende/sense
590 2013-06-22 18:51:02 <Subo1978> try it out
591 2013-06-22 18:54:37 <sipa> both work fine for me
592 2013-06-22 19:01:09 <Subo1978> sipa: not for me. but does not matter. it's all back.
593 2013-06-22 19:21:14 <Vinnie_win> load. We've been waiting for an official fix for months and it hasn't happened." - David Schwartz
594 2013-06-22 19:21:14 <Vinnie_win> sipa: "I don't think they'll have an issue because they don't store as much data in LevelDB as we do and they don't have as much other I/O going on. But the problem is that when LevelDB does a compaction, it writes as fast as it possibly can. This causes all other I/O to encounter orders of magnitude higher latency. The change forces LevelDB to pause between files, smoothing out the I/O
595 2013-06-22 19:23:12 <sipa> Vinnie_win: i see
596 2013-06-22 19:32:50 <maaku> boycey: the meta-chain is a merged mined altchain whose coinbase contains utxo index commits
597 2013-06-22 19:33:12 <maaku> it contains committed meta-data about the chain, hence the name
598 2013-06-22 19:35:25 <maaku> if the utxo meta-data were a manditory part of the bitcoin coinbase format then it wouldn't be needed
599 2013-06-22 19:35:46 <sipa> it can become mandatory
600 2013-06-22 19:35:55 <sipa> and if it's not, how will it be enforced?
601 2013-06-22 19:36:41 <maaku> it's enforced on the meta-chain
602 2013-06-22 19:37:33 <sipa> sure, but that doesn't mean every bitcoin block will commit to a meta-chain node
603 2013-06-22 19:37:34 <maaku> so the process is you download the meta-chain headers from the last checkpoint, download the coinbase of the most-work header, extract the authenticated index roots, and query nodes for data based on those roots
604 2013-06-22 19:38:13 <boycey> maaku: can you post the link to your blog again? It was a while since I was looking at it. (ty)
605 2013-06-22 19:38:21 <sipa> it seems much more useful (and easy) to me if it's just enforced in the bitcoin chain
606 2013-06-22 19:38:28 <sipa> (though perhaps more controversial...)
607 2013-06-22 19:38:34 <maaku> sipa: no it doesn't, so you probably end up a block or two behind, and then download the missing bitcoin blocks
608 2013-06-22 19:38:58 <maaku> boycey: http://utxo.tumblr.com
609 2013-06-22 19:39:16 <sipa> maaku: why one or two? why would anyone bother constructing the meta-chain in the first place? it'll likely be significantly more expensive to maintain
610 2013-06-22 19:41:04 <maaku> sipa: yes, but that expense doesn't impact mining profitability since the meta-chain can be mined asynchronously
611 2013-06-22 19:41:19 <sipa> so, what is the incentive to mine it in the first place?
612 2013-06-22 19:41:44 <maaku> people will run merged-mined meta pools because it is good for bitcoin. the same reason people run full nodes with open port
613 2013-06-22 19:42:06 <maaku> a fully merged mined meta-chain increases the value of bitcoin
614 2013-06-22 19:42:22 <sipa> the way i see it, full nodes determine the rules of the network, and miners are their clients - who try to satisfy the rules of their clients
615 2013-06-22 19:42:36 <maaku> i'm all for full enforcement with a bitcoin soft-fork, however
616 2013-06-22 19:42:45 <sipa> if the utxo commitment is so useful for bitcoin, it should be full nodes that demand it
617 2013-06-22 19:42:57 <maaku> i just think the meta-chain is a controversy-free way to get utxo out in the wild and experimented with first
618 2013-06-22 19:43:01 <sipa> agree
619 2013-06-22 19:58:41 <phantomcircuit> lol i just realized the icedtea JRE java.util.Random.nextLong only returns positive values
620 2013-06-22 20:00:37 <boycey> maaku: what is to stop somebody falsifying the utxo trie, if there is no economic incentive for miners?
621 2013-06-22 20:00:45 <boycey> (51% problem)
622 2013-06-22 20:01:29 <sipa> boycey: miners who do mine on the meta-tree validate it
623 2013-06-22 20:01:55 <sipa> or any full node that is meta-tree enabled, really
624 2013-06-22 20:02:28 <boycey> sipa: but lets say there are multiple different copies of the trie about, some fake, some real. how does a client know which one to trust?
625 2013-06-22 20:02:30 <maaku> boycey: why would you 51% attack the meta tree?
626 2013-06-22 20:02:48 <maaku> boycey: it trusts the longest chain
627 2013-06-22 20:02:51 <boycey> maaku: to make a double spend..
628 2013-06-22 20:03:27 <sipa> yeah, that's why it's much safer if every full (and thus miner) enforces it
629 2013-06-22 20:03:33 <maaku> if there is sufficient adoption of the meta-chain, that is the same as a 51% attack on bitcoin
630 2013-06-22 20:03:57 <sipa> if, yes :)
631 2013-06-22 20:05:41 <boycey> maaku: well, its all very well saying: let's just force miners to mine this new txo chain. But there is no economic incentive there for them to mine it. however, if people are relying on this chain for verifying transactions, there is definitely an incentive there for people with the computational capacity available to falsify it.
632 2013-06-22 20:05:42 <maaku> yes, but it only takes a handful of pools to get a significant fraction of bitcoin's hash power
633 2013-06-22 20:06:38 <boycey> maaku: that's the reason why bitcoin works so well? its the economic incentive for the miners
634 2013-06-22 20:06:39 <maaku> boycey: only lightweight clients rely on the utxo info from the meta-chain
635 2013-06-22 20:07:04 <maaku> clients which currently have LESS security than relying on the utxo would provide
636 2013-06-22 20:09:20 <boycey> maaku: can you make these clients pay a fee to anybody who mines utxo?
637 2013-06-22 20:09:41 <maaku> i don't think that's a good idea
638 2013-06-22 20:10:11 <maaku> maybe you could develop a micropayment system for utxo queries
639 2013-06-22 20:10:28 <maaku> but that would be strictly on top of this layer
640 2013-06-22 20:10:42 <maaku> i do not think it is a good idea to monetize the meta-chain in any way
641 2013-06-22 20:14:45 <maaku> boycey: i do not agree that bitcoin's success is due to economic incentive for miners
642 2013-06-22 20:15:14 <boycey> maaku: "i do not think it is a good idea to monetize the meta-chain in any way" = > you say monetize, i say incentivize
643 2013-06-22 20:15:40 <sipa> there should not be any incentive to mine, except for the fact that people demand it
644 2013-06-22 20:16:01 <maaku> if you making meta-chain worth anything, you are monetizing it
645 2013-06-22 20:16:08 <sipa> and i'm not sure how that'd work with a separate chain
646 2013-06-22 20:16:26 <boycey> oh my god. where is satoshi?????
647 2013-06-22 20:16:30 <sipa> but i agree that the technical part of the system can be implemented in a meta-chain initially
648 2013-06-22 20:16:37 <sipa> so it can be developed and mature
649 2013-06-22 20:16:57 <sipa> and once deemed sufficiently useful and ready, it can be integrated as mandatory part of the main chain