1 2013-11-27 00:00:24 <gmaxwell> Some journalists did... they have basically infinite capacity to take crazy things seriously, it seems. :)
  2 2013-11-27 00:01:14 <sipa> i don't think we can blame journalists for that
  3 2013-11-27 00:01:28 <sipa> well, they can always do better fact checking of course
  4 2013-11-27 00:01:53 <sipa> but it's not unreasonable to take a paper authored by shamir seriously, if you don't know better
  5 2013-11-27 00:02:30 <cfields> "i think you are satoshi m8"
  6 2013-11-27 00:03:01 <cfields> nothing like giving a well-reasoned argument, only to have someone respond with "nuh-uh".
  7 2013-11-27 00:03:32 <gavinandresen> ekkis: no, not here.
  8 2013-11-27 00:03:36 <shesek> lol, someone on HN commented: "General consensus seems to be that Ron&Shamir's publications on this topic are extraordinarily weak given how stellar a record Shamir, in particular, has. The conclusion seems obvious: It's a misdirection. Adi Shamir is Satoshi Nakamoto."
  9 2013-11-27 00:03:41 <ekkis> sipa: yes but it's not difficult to know better
 10 2013-11-27 00:04:03 <shesek> (followed up with "Note: No, I do not in fact believe this.")
 11 2013-11-27 00:04:12 <Diablo-D3> shesek: not that shit again
 12 2013-11-27 00:04:17 <Diablo-D3> I know who satoshi is
 13 2013-11-27 00:04:18 <Diablo-D3> it isnt him
 14 2013-11-27 00:04:26 <ekkis> gavinandresen: hei! I wanted to follow up on Scott Hanselman. I gather with this much commotion you've been busy but Scott would be a good guy to talk to.  did you get his e-mail?
 15 2013-11-27 00:05:03 <gavinandresen> ekkis: ah, right…. that got buried in my inbox.  I'll dig it up when I have time.
 16 2013-11-27 00:05:41 <gavinandresen> ekkis: frankly, right now doing interviews is at the bottom of my priority list.  Bitcoin has too much publicity already.
 17 2013-11-27 00:05:52 <LockAndCaps> https://en.bitcoin.it/wiki/URI_Scheme <-- I don't understand how the hell I'm supposed to put the "amount" parameter. Those "numbers" don't make any sense to me, and anything I put in is considered malformed by the Bitcoin-qt client.
 18 2013-11-27 00:06:18 <sipa> LockAndCaps: see the first line
 19 2013-11-27 00:07:28 <quellhorst> how can i get the master_public_key of my bitcoin wallet?
 20 2013-11-27 00:08:03 <maaku> quellhorst: there isn't one
 21 2013-11-27 00:08:16 <maaku> what are you looking for?
 22 2013-11-27 00:08:27 <sipa> LockAndCaps: i replaced the page with a proper redirect
 23 2013-11-27 00:08:31 <LockAndCaps> sipa: Um... so it's not a standard?
 24 2013-11-27 00:08:57 <LockAndCaps> Hmm...
 25 2013-11-27 00:08:57 <sipa> LockAndCaps: it was a proposed standard that nobody adopted
 26 2013-11-27 00:09:05 <LockAndCaps> No wonder -- it's damn confusing.
 27 2013-11-27 00:09:11 <LockAndCaps> At least the part I was trying to get working.
 28 2013-11-27 00:09:14 <LockAndCaps> AKA the amount.
 29 2013-11-27 00:10:43 <edcba> ok my address book is "all" wrong
 30 2013-11-27 00:12:06 <quellhorst> maaku: https://github.com/prusnak/addrgen/tree/master/ruby
 31 2013-11-27 00:12:16 <quellhorst> i need the master public key to pre generate addresses
 32 2013-11-27 00:12:31 <edcba> i have some entry with label "1AA..." (normal addr) with its associated addr "1AAaaa"
 33 2013-11-27 00:12:46 <edcba> other entries look fine
 34 2013-11-27 00:13:06 <sipa> quellhorst: "of my bitcoin wallet"... what software?
 35 2013-11-27 00:13:09 <danneu> quellhorst: you supply your own for that lib
 36 2013-11-27 00:13:15 <edcba> also another entry with no label and with address of previous label
 37 2013-11-27 00:13:33 <quellhorst> i'm using bitcoind
 38 2013-11-27 00:13:45 <sipa> bitcoind doesn't have deterministic address generation at all
 39 2013-11-27 00:13:47 <sipa> (yet)
 40 2013-11-27 00:14:00 <quellhorst> so i need to use another wallet with that lib then?
 41 2013-11-27 00:14:15 <sipa> i'm not sure what you're trying to do
 42 2013-11-27 00:14:23 <sipa> that library is to generate keys
 43 2013-11-27 00:14:28 <quellhorst> i'm trying to make a bunch of addresses beforehand to be used on a website for payments
 44 2013-11-27 00:14:42 <quellhorst>   BitcoinAddrgen.generate_public_address(master_public_key, address_index)
 45 2013-11-27 00:14:46 <quellhorst> its for generating addresses
 46 2013-11-27 00:14:56 <sipa> you can use that to create addresses, and then import them into bitcoind
 47 2013-11-27 00:15:02 <quellhorst> exactly
 48 2013-11-27 00:15:03 <sipa> uusing importprivkey <key> 0
 49 2013-11-27 00:15:09 <sipa> eh
 50 2013-11-27 00:15:10 <quellhorst> so how do i get my master_public_key ?
 51 2013-11-27 00:15:15 <sipa> you choose one
 52 2013-11-27 00:15:16 <danneu> quellhorst: you invent one
 53 2013-11-27 00:15:18 <sipa> and keep it very secret
 54 2013-11-27 00:15:25 <edcba> is there an offline tool to generate some crafted transactions ?
 55 2013-11-27 00:15:33 <quellhorst> ok, is there any page on making a new master public key?
 56 2013-11-27 00:15:56 <edcba> alternatively you give me your master_public_key and forget it
 57 2013-11-27 00:16:10 <danneu> that's actually weird. i would think you supply master-privkey
 58 2013-11-27 00:16:11 <shesek> edcba, bitcoind?
 59 2013-11-27 00:16:20 <quellhorst> edcba: why don't i just transfer funds to you ?
 60 2013-11-27 00:16:38 <quellhorst> yeah, so if its a public key, it shouldn't be that unsafe
 61 2013-11-27 00:16:38 <sipa> please
 62 2013-11-27 00:16:39 <maaku> quellhorst: if you use a website to generate your key you might as well be doing that
 63 2013-11-27 00:16:59 <quellhorst> so, can i get the master_public_key out of an existing wallet.dat?
 64 2013-11-27 00:17:05 <sipa> quellhorst: it doesn't have one
 65 2013-11-27 00:17:08 <quellhorst> ok
 66 2013-11-27 00:17:12 <danneu> quellhorst: https://github.com/wink/money-tree read that
 67 2013-11-27 00:17:16 <sipa> quellhorst: it's something that only makes sense in the context of that tool
 68 2013-11-27 00:17:25 <sipa> quellhorst: you don't have to use that tool
 69 2013-11-27 00:17:41 <sipa> quellhorst: you can just increase the number of keys in your wallet beforehand to a high number, and be done with it
 70 2013-11-27 00:18:07 <quellhorst> hmm, how can i do say 1000 new keys in bitcoind beforehand?
 71 2013-11-27 00:18:14 <edcba> shesek: yeah maybe bitcoind should be enough
 72 2013-11-27 00:18:15 <sipa> start with -keypoolsize=1000
 73 2013-11-27 00:18:23 <quellhorst> and then how do i get a list of all them?
 74 2013-11-27 00:18:25 <Apocalyptic> quellhorst, you increase the keypoolsize
 75 2013-11-27 00:18:27 <sipa> you don't
 76 2013-11-27 00:18:32 <sipa> you request one when you need one
 77 2013-11-27 00:18:45 <maaku> sipa: i think he wants the bitcoind offline / not connected
 78 2013-11-27 00:18:48 <quellhorst> part of security is that i won't have it online when i need a new one
 79 2013-11-27 00:18:52 <quellhorst> maaku: exactly
 80 2013-11-27 00:19:15 <edcba> i almost need that too :)
 81 2013-11-27 00:19:31 <danneu> that's what i was working on until i started putzing with op-checksig
 82 2013-11-27 00:19:39 <sipa> maaku: ok, so one way to do it is call getnewaddress a 1000 times, then copy the wallet file, encrypt it with a random password that you don't even know yourself, and copy that encrypted wallet to the server
 83 2013-11-27 00:19:45 <sipa> eh, quellhorst ^
 84 2013-11-27 00:20:01 <sipa> until we have bip32 + watch-only addresses that's probably the best way
 85 2013-11-27 00:20:18 <danneu> is there no wallet that supports bip32 with public-key watch?
 86 2013-11-27 00:20:38 <sipa> maybe, i haven't followed up
 87 2013-11-27 00:20:44 <sipa> but none of the major ones
 88 2013-11-27 00:20:52 <danneu> ah
 89 2013-11-27 00:21:50 <quellhorst> sipa: ok, so run getnewaddress 1000 times, and record each address. how do i then access each wallet's funds?
 90 2013-11-27 00:21:55 <quellhorst> or do they all go to one master account?
 91 2013-11-27 00:22:29 <sipa> you only have one wallet
 92 2013-11-27 00:23:05 <quellhorst> do the payments somehow get aggregated? or can someone externally not tell they are all in the same wallet?
 93 2013-11-27 00:23:30 <quellhorst> oh, i see each address will have its own keypair with bitcoind?
 94 2013-11-27 00:23:45 <danneu> that's some kludge
 95 2013-11-27 00:24:15 <quellhorst> yeah, now i see the reason behind money-tree
 96 2013-11-27 00:25:06 <CodeShark> the bitcoin protocol itself has no concept of accounts or wallets
 97 2013-11-27 00:25:37 <danneu> dunno if that really helps quellhorst
 98 2013-11-27 00:26:12 <CodeShark> it has the concept of transactions, which consume outputs and create new outputs
 99 2013-11-27 00:26:19 <danneu> quellhorst just tryin to hustle
100 2013-11-27 00:26:38 <quellhorst> danneu: this helps me some
101 2013-11-27 00:27:00 <quellhorst> but it sounds like high risk generating a new key all the time with bitcoind
102 2013-11-27 00:27:08 <CodeShark> each output can have a unique signing key if you want
103 2013-11-27 00:27:24 <CodeShark> it's up to the wallet software to organize them into accounts
104 2013-11-27 00:27:24 <quellhorst> somewhere i read i need a new backup after each new key is made
105 2013-11-27 00:27:33 <danneu> quellhorst: the bottom line is that bitcoind just doesnt yet implement the spec that things like money-tree have implemented
106 2013-11-27 00:27:37 <danneu> so atm it's a bit rough
107 2013-11-27 00:27:57 <CodeShark> quellhorst: unfortunately, bitcoind automatically fills the keypool without prompting the user
108 2013-11-27 00:28:06 <CodeShark> it's a defect in design, if you ask me :p
109 2013-11-27 00:28:09 <Luke-Jr> …
110 2013-11-27 00:28:12 <Luke-Jr> it never hurts
111 2013-11-27 00:28:26 <CodeShark> it hurts a lot - because you have to remember when to make backups - and old backups expire without warning
112 2013-11-27 00:28:55 <Luke-Jr> maybe.
113 2013-11-27 00:28:57 <danneu> expire?
114 2013-11-27 00:29:07 <Luke-Jr> I suppose better behaviour would be to fill the keypool when making a backup..
115 2013-11-27 00:29:17 <CodeShark> yes, absolutely, Luke-Jr
116 2013-11-27 00:29:33 <CodeShark> that's really the purpose of having a keypool in the first place
117 2013-11-27 00:29:36 <danneu> i would think old backups always contain a subset of your keys, not expire
118 2013-11-27 00:29:37 <CodeShark> being able to make batch backups
119 2013-11-27 00:30:04 <CodeShark> https://github.com/bitcoin/bitcoin/pull/2841
120 2013-11-27 00:30:33 <CodeShark> when I do a getinfo, I love knowing how much longer I've got until I need to make a new backup
121 2013-11-27 00:32:32 <CodeShark> danneu: they expire because the automatic keypool refills create new keys which might get used before you've made a new backup
122 2013-11-27 00:33:04 <CodeShark> eventually you might end up with practically all your coins protected by keys that are not part of the old backup at all
123 2013-11-27 00:33:23 <edcba> so account is a collection of addresses ?
124 2013-11-27 00:34:08 <CodeShark> edcba: almost. more accurate, an account is a collection of signing scripts
125 2013-11-27 00:34:40 <CodeShark> output scripts you give others, and input scripts you sign with keys only you have
126 2013-11-27 00:34:49 <danneu> common answers to common output scripts
127 2013-11-27 00:34:55 <CodeShark> yes
128 2013-11-27 00:35:44 <CodeShark> signing scripts are then mapped to addresses
129 2013-11-27 00:35:50 <edcba> it seems i labeled some output address in my address book and with recent versions processing of it is borked...
130 2013-11-27 00:36:34 <CodeShark> although my usage of "account" here does not correspond to the usage in bitcoind
131 2013-11-27 00:36:42 <edcba> damn
132 2013-11-27 00:36:55 <CodeShark> in bitcoind, the concept we've just stated is simply called a "wallet"
133 2013-11-27 00:37:39 <CodeShark> so yeah, I guess in bitcoind an "account" is a collection of receiving addresses
134 2013-11-27 00:37:48 <CodeShark> although not exactly :p
135 2013-11-27 00:37:51 <CodeShark> damn
136 2013-11-27 00:37:56 <Luke-Jr> …
137 2013-11-27 00:38:00 <Luke-Jr> addresses are only receiving
138 2013-11-27 00:38:05 <Apocalyptic> you're confusing yourself CodeShark
139 2013-11-27 00:38:09 <CodeShark> heh
140 2013-11-27 00:38:15 <Luke-Jr> they point at an account, but they aren't part of the account
141 2013-11-27 00:38:24 <Apocalyptic> better forget about accounts imo
142 2013-11-27 00:38:45 <Luke-Jr> accounts work fine :P
143 2013-11-27 00:38:55 <Apocalyptic> they do now ? :)
144 2013-11-27 00:39:33 <CodeShark> what happens in bitcoind if you add an address to an account and receive coins at that address…then move the address to a different account…then receive more coins at that address?
145 2013-11-27 00:40:16 <CodeShark> more interestingly, what happens if in the meantime the original transaction is replaced with a different one for a different amount? (say, the original transaction gets doublespent)
146 2013-11-27 00:40:40 <CodeShark> or not doublespent, but a blockchain reorg kills it
147 2013-11-27 00:41:30 <CodeShark> there's no way generally to determine what occured first: the reorg or the changing of account
148 2013-11-27 00:41:38 <edcba> ok so i have an excerpt of my wallet dump : http://pastebin.com/DCxDg9Nm
149 2013-11-27 00:41:55 <edcba> and the 18ccccc is causing some trouble it seems
150 2013-11-27 00:42:22 <danneu> Would the blockchain validate if I always queried for the most recent duplicate-txn-hash?
151 2013-11-27 00:43:16 <CodeShark> so would the new transaction's coins be part of the first account or the second?
152 2013-11-27 00:45:06 <CodeShark> concretely, 1) getnewaddress account1; 2) you receive a coin at that address; 3) setaccount <address> account2; 4) block chain reorg, original coin gets doublespent
153 2013-11-27 00:45:21 <CodeShark> is that coin now in account 1 or account 2?
154 2013-11-27 00:45:43 <CodeShark> or rather...
155 2013-11-27 00:46:03 <gmaxwell> IIRC it's 'stateless' e.g. the moves are as if they always were.
156 2013-11-27 00:46:06 <CodeShark> concretely, 1) getnewaddress account1; 2) you receive a coin at that address; 3) setaccount <address> account2; 4) block chain reorg, original coin gets spent to same address bit in different transactions
157 2013-11-27 00:46:17 <gmaxwell> as it doesn't keep an account balance really, it just replays the data.
158 2013-11-27 00:46:39 <CodeShark> so then anything you ever received at that address would now move from account1 to account2?
159 2013-11-27 00:47:05 <CodeShark> we could complicate the situation a tad by sticking a move somewhere in there as well
160 2013-11-27 00:47:10 <Dickyb0b> http://www.youtube.com/watch?v=ReS6_syD_U8
161 2013-11-27 00:47:20 <Dickyb0b> you guys aware of this?
162 2013-11-27 00:48:00 <gmaxwell> CodeShark: yes, thats what it does.
163 2013-11-27 00:48:24 <gmaxwell> CodeShark: when you set account its as though that address were always assigned to that account.
164 2013-11-27 00:48:51 <gmaxwell> and moves are just free ledger entries that assign value, accounts can have negative value.
165 2013-11-27 00:49:04 <CodeShark> ok, so then say you do 1) getnewaddress account1; 2) you receive coins; 3) move from account1 to account2; 4) setaccount <address> account2
166 2013-11-27 00:49:37 <gmaxwell> Dickyb0b: no, hadn't heard of it. I don't know that any bitcoin software developers are there either?
167 2013-11-27 00:50:08 <Dickyb0b> i didnt as well
168 2013-11-27 00:50:09 <CodeShark> ah, ok - so if you had moved from account1 to account3, say, then setaccount <address> account2, account1 goes negative
169 2013-11-27 00:52:06 <CodeShark> so then an account in bitcoind is a grouping of receiving addresses into labeled sets, each set also potentially having an offset such that all offsets for all accounts add to 0
170 2013-11-27 00:52:41 <CodeShark> too complicated :p
171 2013-11-27 00:53:03 <edcba> is that normal i have some address with getreceivedbyaddress > 0 and not showing on transactions ?
172 2013-11-27 00:53:24 <edcba> or maybe it is within "payment to self"...
173 2013-11-27 00:53:31 <quellhorst> Dickyb0b: thanks for that link
174 2013-11-27 00:53:39 <CodeShark> bitcoind hides change outputs
175 2013-11-27 00:53:40 <Dickyb0b> yw
176 2013-11-27 00:54:08 <edcba> "payment to self" are completely emulated transactions ?
177 2013-11-27 00:54:19 <edcba> ie they don't show up in blockchain ?
178 2013-11-27 00:54:31 <CodeShark> moves within the wallet don't show up in block chain
179 2013-11-27 00:54:50 <CodeShark> explicit payments to self, as well as change, does show up in block chain
180 2013-11-27 00:54:57 <Apocalyptic> edcba, "payment to self" is ambigous
181 2013-11-27 00:55:10 <CodeShark> by moves I'm just talking account moves, not sendtoaddress
182 2013-11-27 00:55:17 <Apocalyptic> if it's a move it doesn't, if you send to another address in the wallet it does
183 2013-11-27 00:55:21 <CodeShark> sendtoaddress does appear in blockchain
184 2013-11-27 00:55:31 <CodeShark> even if within the same wallet
185 2013-11-27 00:57:28 <CodeShark> anyhow, thanks to bitcoind graciously hiding its own change outputs, it is indeed possible for getreceivedbyaddress to return nonzero while listtransactions omits any mention of that address
186 2013-11-27 00:58:10 <edcba> ok that "payment to self" definitely show to blockchain
187 2013-11-27 00:58:13 <CodeShark> I remember about a week into starting to learn about bitcoin going mad because the block chain showed outputs I couldn't see in my client :p
188 2013-11-27 00:58:20 <edcba> still the client doesn't tell me anything
189 2013-11-27 00:58:24 <edcba> fuck that client
190 2013-11-27 00:59:12 <edcba> i wonder if those coins are somewhere in my total balance
191 2013-11-27 00:59:21 <CodeShark> I guess the thought that went into the design was "the user will never need to know the change output even exists so getreceivedbyaddress will never be called on it"
192 2013-11-27 00:59:21 <gmaxwell> all the information is available in bitcoin-qt, just not shown in the transaction list. BC.i has a lot of things which aren't available or are misleadingly displayed.
193 2013-11-27 00:59:26 <quellhorst> Dickyb0b: lol "have any of you ever been on an irc channel"
194 2013-11-27 00:59:42 <Dickyb0b> yeh i just heard that
195 2013-11-27 00:59:43 <CodeShark> and this logic quickly breaks down as soon as you start to use tools like blockchain.info or blockexplorer
196 2013-11-27 00:59:49 <Dickyb0b> its not dead lol
197 2013-11-27 00:59:57 <CodeShark> or even getrawtransaction
198 2013-11-27 01:00:16 <edcba> yeah it's not dead just "idling" :p
199 2013-11-27 01:00:21 <quellhorst> Dickyb0b: yeah, i thought "noobs" when i heard that
200 2013-11-27 01:00:28 <gmaxwell> edcba: in bitcoin-qt you can find out about all the coins you can spend in excruicating detail with listunspent.
201 2013-11-27 01:00:41 <edcba> ok i try...
202 2013-11-27 01:01:27 <Dickyb0b> do you have to use a fan for all usb stick mining?
203 2013-11-27 01:01:57 <Dickyb0b> thinking of getting 2x bi*furys at 5gh each
204 2013-11-27 01:03:46 <quellhorst> Dickyb0b: how much are they? I saw quite a few for sale on ebay
205 2013-11-27 01:04:27 <Dickyb0b> a seller is offering me  two for £575.
206 2013-11-27 01:05:03 <edcba> ok i think the problem with client is we can label addresses and use accounts
207 2013-11-27 01:05:18 <ekkis> gavinandresen: yes, I agree.  publicity is certainly not lacking today.  ok, no worries.  somewhere down the road when you have time.  I can always reach out to him
208 2013-11-27 01:06:22 <Dickyb0b> ;;genrate 10000
209 2013-11-27 01:06:23 <gribble> The expected generation output, at 10000.0 Mhps, given difficulty of 609482679.888, is 0.00825136682347 BTC per day and 0.000343806950978 BTC per hour.
210 2013-11-27 01:06:51 <edcba> hmm
211 2013-11-27 01:06:54 <tim`> ;;genrate 60000
212 2013-11-27 01:06:55 <gribble> The expected generation output, at 60000.0 Mhps, given difficulty of 609482679.888, is 0.0495082009408 BTC per day and 0.00206284170587 BTC per hour.
213 2013-11-27 01:07:06 <edcba> how much is gpu ?
214 2013-11-27 01:07:08 <edcba> 100 ?
215 2013-11-27 01:07:19 <tim`> depends on the gpu doesnt it
216 2013-11-27 01:07:35 <tim`> https://en.bitcoin.it/wiki/Mining_hardware_comparison
217 2013-11-27 01:08:09 <edcba> ok
218 2013-11-27 01:08:25 <edcba> indeed quite useless to use gpu these days
219 2013-11-27 01:08:28 <Dickyb0b> i would make £30 a week at the current difficulty with 10GH
220 2013-11-27 01:09:24 <Dickyb0b> but the diff is going to change
221 2013-11-27 01:09:32 <edcba> for sure lol
222 2013-11-27 01:09:51 <tim`> almost that time :{
223 2013-11-27 01:11:42 <ekkis> can I ask a dumb question? the number of transactions in a block affects the cost of generating a hash.  I gather that at the time of the protocol design it was deemed that 10min was enough time given the speed of computers for someone to figure out the right hash? and now the number of transactions has significantly increased, as well as the computing power dedicated to the task? so my question: wouldn't it make sense to shorten the length of the i
224 2013-11-27 01:11:42 <ekkis> nterval? that way there would be fewer transactions per block, and a shorter interval would mean a shorter time for a hacker to fork i.e. if I'm successful in calculating the hash in 1 sec (because I have such powerful hardware) then I have 9min 59sec to perhaps recompute previous blocks
225 2013-11-27 01:12:29 <ekkis> it means we could reach the 6 verification quorum faster
226 2013-11-27 01:13:06 <edcba> hashes are very fast to compute
227 2013-11-27 01:13:18 <tim`> its just a race of rates isnt it ? not sure the quantization matters that much
228 2013-11-27 01:14:12 <ekkis> edcba: but isn't that an argument for shortening the timespan of the block?
229 2013-11-27 01:14:14 <edcba> ekkis: anyway we can't really change block rate
230 2013-11-27 01:15:09 <ekkis> I was just thinking that there must have been some forethought to the fact that the machinery used to hash would significantly increase in capacity
231 2013-11-27 01:15:23 <edcba> i think block rate has been setup so it wouldn't cause problems with network propagation
232 2013-11-27 01:15:24 <ekkis> and I'm wondering how that doesn't constitute a path for attack
233 2013-11-27 01:15:36 <edcba> if too fast many splits
234 2013-11-27 01:17:02 <Dickyb0b> bitcoin is nearly at 900 usd
235 2013-11-27 01:17:07 <ekkis> well? to successfully forge a transaction I would have to compute the correct hash on the current block before anyone else does _and_ recompute the previous block as well? the longer the timespan the more chances I have to do it, no?
236 2013-11-27 01:17:45 <edcba> yes the longer the chain the most secure it is
237 2013-11-27 01:18:09 <edcba> satoshi just decided on some constants that's all
238 2013-11-27 01:18:16 <edcba> not much we can change easily now
239 2013-11-27 01:18:18 <ekkis> but you don't need to recompute the whole chain.  only the previous block
240 2013-11-27 01:19:09 <edcba> that kind of attack depends on difficulty
241 2013-11-27 01:19:28 <ekkis> right, which depends on the timespan available to the attacker i.e. 10min
242 2013-11-27 01:19:46 <edcba> and that's why satoshi told us to wait for 6 blocks for a tx to be 'really' confirmed
243 2013-11-27 01:19:55 <ekkis> which at one hashrate means one risk and at a much higher hashrate means much higher risk
244 2013-11-27 01:20:32 <ekkis> ya.  I get the reason for the 6 block recommendation
245 2013-11-27 01:21:38 <gmaxwell> edcba: uhhhh 6 is not a network parameter.
246 2013-11-27 01:21:47 <gmaxwell> And it's not some holy caved in stone thing.
247 2013-11-27 01:22:14 <gmaxwell> It's just a not crazy rule of thumb. Though for high value transactions more is likely prudent now due to hashpower consolidation.
248 2013-11-27 01:22:33 <gmaxwell> (high value, and no trust/recourse— of course)
249 2013-11-27 01:23:23 <quidnunc> Can anyone get this mtgox node.js library to work? I try to run demo.js and I get no data https://github.com/olalonde/mtgox-socket-client
250 2013-11-27 01:23:42 <ekkis> gmaxwell: higher hashpower represents higher risk of an attack, given the same timespan for a block no? so a shorter timespan would reduce the risk.  do you see it that way?
251 2013-11-27 01:23:43 <Apocalyptic> this is the wrong channel for that
252 2013-11-27 01:24:14 <quidnunc> Apocalyptic: What is the right channel?
253 2013-11-27 01:24:23 <edcba> #mtgox ?
254 2013-11-27 01:24:29 <Dickyb0b> http://www.bitlisten.com
255 2013-11-27 01:24:30 <quidnunc> edcba: haha
256 2013-11-27 01:24:32 <mappum> quidnunc: probably #node.js
257 2013-11-27 01:24:53 <quidnunc> mappum: yeah, maybe
258 2013-11-27 01:25:20 <mappum> does there already exist an altcoin that gets miners to store data? if not, i have a proposal
259 2013-11-27 01:25:25 <Dickyb0b> 
ACTION wonders when a nice tune is played

260 2013-11-27 01:25:34 <gmaxwell> ekkis: "shorter timespan" between blocks?  No. shorter timespans between blocks mean more hashpower dillution due to chance forking.
261 2013-11-27 01:26:14 <gmaxwell> (the difference between 10 and 5 minutes, say, at current network latencies is probably not a big deal however— but at some point it breaks down, with sufficiently fast blocks no amount of confirmations is safe)
262 2013-11-27 01:26:35 <ekkis> gmaxwell: and the chance for forking rises because there is greater contention between the parties for who gets there first?
263 2013-11-27 01:27:14 <ekkis> gmaxwell: hmm? that's what I want to understand better.  what do you recommend I read?
264 2013-11-27 01:27:20 <gmaxwell> ekkis: right, the time between blocks need to be high enough given latencies and node speeds that contention is rare. If its not rare then a benefit is confered to hashpower consolidations and uncertanty of the longest chain is increased.
265 2013-11-27 01:27:43 <edcba> i guess fork probability relates to block time/propagation
266 2013-11-27 01:28:25 <edcba> anyway i guess all that is explain in bitcoin paper
267 2013-11-27 01:28:33 <edcba> explained
268 2013-11-27 01:28:49 <gmaxwell> not in great detail but if you haven't read it yet you really should stop gabbing here and read it.
269 2013-11-27 01:28:56 <ekkis> gmaxwell: if I receive notification of a successful hash calculation, I still have the block that I was working on and thus can verify that the transactions on the supposedly successful block match those in mine.  thus I can agree or disagree, right?
270 2013-11-27 01:29:28 <ekkis> I'll re-read the whitepaper
271 2013-11-27 01:29:35 <gmaxwell> ekkis: they won't match, not completely, and it's not important that they match in any particular way.
272 2013-11-27 01:29:36 <Dickyb0b> so many transactions on bitlisten
273 2013-11-27 01:29:41 <mappum> ekkis: you don't have to be a miner to agree, any node can go through and verify
274 2013-11-27 01:29:44 <edcba> you won't accept a block with a 'wrong' transaction
275 2013-11-27 01:30:05 <gmaxwell> edcba: wrong, sure, but matching has nothing to do with correctness.
276 2013-11-27 01:30:13 <edcba> yes :)
277 2013-11-27 01:30:30 <ekkis> correct means that it contains the same number of transactions for the same total value, yes?
278 2013-11-27 01:30:32 <gmaxwell> the whole purpose of mining is to reach an agreement about the ordering of transactions— including which txn are in the set or not.
279 2013-11-27 01:30:46 <gmaxwell> ekkis: no absolutely not.
280 2013-11-27 01:30:57 <edcba> ekkis: correct means nobody spent some money he hasn't :p
281 2013-11-27 01:30:59 <gmaxwell> Correct just means that the transaction data is consistent with the rules of the network.
282 2013-11-27 01:31:15 <gmaxwell> that all the coins spent existed, etc.
283 2013-11-27 01:31:41 <edcba> the block you were trying to mine may have a double spending not matching the one actually mined
284 2013-11-27 01:32:00 <edcba> both are 'correct'
285 2013-11-27 01:32:25 <ekkis> hmm? I see
286 2013-11-27 01:32:27 <edcba> but you can't have a block with both those transactions
287 2013-11-27 01:32:58 <edcba> block/blockchain
288 2013-11-27 01:33:11 <ekkis> all right.  time for me to head home.  laters guys
289 2013-11-27 01:38:10 <edcba> geettransaction doesn't give you inputs ?
290 2013-11-27 01:41:23 <Dickyb0b> lol bitlisten went quite,then the whole screen came up with loads
291 2013-11-27 02:17:32 <hydromet> hello
292 2013-11-27 02:18:26 <hydromet> I understand there is a bounty available with regard to solving a problem with LevelDB  -- Bitcoin-Qt for OS X eh?
293 2013-11-27 02:18:33 <hydromet> http://www.zdnet.com/bitcoin-developers-offer-10000-virtual-bounty-to-fix-mystery-mac-bug-7000023632/
294 2013-11-27 02:20:06 <hydromet> Has anyone solved it yet? If not, given the pains I went through to compile Bitcoin-Qt 0.8.5 on OS X (following mostly Gavin's approach), I may be up for giving it a try to see if I can resolve it.
295 2013-11-27 02:20:56 <hydromet> any idea of how many other people on the planet have gone through the pains of compiling 0.8.5 from source for OS X?
296 2013-11-27 02:22:03 <hydromet> btw, I upgraded my Mac to OS X 10.9 (the 0.8.5 compile was initially on my Mac running OS X 10.8.5) ... if I recall correctly, I think Gavin was running his test MacBook with OS X 10.7.x aka "Lion"?
297 2013-11-27 02:29:34 <warren> cfields: one report from a mac user, prior to that patch it was corrupting on every run, now it isn't.
298 2013-11-27 02:35:27 <warren> cfields: did you PR the memory barrier patch?  It seemed to have fixed something
299 2013-11-27 02:48:12 <CodeShark> did cfields fix the mac corruption issue? :)
300 2013-11-27 02:51:12 <Burritoh> will he get the bounty, then?
301 2013-11-27 02:51:21 <Burritoh> That's a pretty fancy bounty.
302 2013-11-27 02:54:21 <CodeShark> warren: a user that had it corrupting on every run seems like a great resource for tracking the issue down :)
303 2013-11-27 02:54:50 <warren> CodeShark: that's only one reporter, need others
304 2013-11-27 02:55:47 <CodeShark> warren: well, hopefully we can figure out exactly *why* it was happening and not just assume it's fixed because people can no longer reproduce it :)
305 2013-11-27 02:56:41 <CodeShark> of course, the issue could have multiple causes
306 2013-11-27 02:57:34 <CodeShark> but arriving at a deductive reason for *why* it was corrupting for one particular user who could reproduce the corruption reliably seems like a breakthrough
307 2013-11-27 02:57:45 <warren> CodeShark: read his analysis?  that's a pretty good reason
308 2013-11-27 02:58:03 <warren> CodeShark: I'm pretty sure we had multiple issues though
309 2013-11-27 02:59:28 <CodeShark> where's the analysis, warren?
310 2013-11-27 03:00:48 <gmaxwell> CodeShark: on the forum, but it's pretty simple, leveldb was using an asm(memory) block as a memory barrier and clang was optimizing it out completely.
311 2013-11-27 03:01:14 <gmaxwell> There was seperate OSX specific memory barrier code already there but the order of the ifdefs made it not get used.
312 2013-11-27 03:01:52 <CodeShark> so this is a leveldb bug, then
313 2013-11-27 03:01:54 <gmaxwell> "Clang completely optimized out my assembly" is a problem I had several times with libtheora and older versions of clang.
314 2013-11-27 03:02:14 <gmaxwell> CodeShark: well, a clang bug + leveldb code not doing what was intended.
315 2013-11-27 03:02:20 <CodeShark> right
316 2013-11-27 03:02:53 <gmaxwell> but I think its somewhat unlikely that this explains all the reported corruption, since gavin hit it some on clang 3.3 64bit build.
317 2013-11-27 03:03:07 <gmaxwell> but perhaps what gavin saw was the fsync stuff.
318 2013-11-27 03:03:17 <cfields> gmaxwell: and also because releases are built with gcc :)
319 2013-11-27 03:03:34 <cfields> but it's a apples mangled version, so there's no telling what it actually does
320 2013-11-27 03:03:39 <cfields> *apple's
321 2013-11-27 03:03:43 <gmaxwell> hmm.
322 2013-11-27 03:03:51 <gmaxwell> I'd forgotten that temporarily.
323 2013-11-27 03:04:22 <cfields> asm dumps seem to show the barrier working in gcc. but for sure not with clang.
324 2013-11-27 03:04:31 <gmaxwell> In any case this is the third issue we've found that was probably causing OSX corruption sometimes for somepeople, god knows— it wouldn't be shocking to find more.
325 2013-11-27 03:04:34 <cfields> and when the framework barrier is added, it's rearranged even further
326 2013-11-27 03:05:05 <warren> with 0.8.5-OMG3 coblee was corrupting on every try
327 2013-11-27 03:05:28 <cfields> so, i felt pretty good about it initially, but more tests leave me more unsure
328 2013-11-27 03:05:47 <warren> cfields: I asked the public for more test reports ... so far it's only coblee's test results
329 2013-11-27 03:05:53 <cfields> i've found 2 more potential leveldb bugs, patching them up now
330 2013-11-27 03:05:58 <warren> he wasn't able to use Bitcoin-Qt at all prior to this
331 2013-11-27 03:06:14 <cfields> also, i got my hands on a 10.8 macbook, but it won't corrupt no matter what evil things i do to it
332 2013-11-27 03:06:57 <CodeShark> strange...
333 2013-11-27 03:07:01 <cfields> well that's interesting, but i'm afraid this kind of bug is going to require lots of validation
334 2013-11-27 03:08:57 <gmaxwell> warren: I'd worry in that kind of case that the problem was something else entirely and the change merely shuffled things around in memory and now it just appears to work right.
335 2013-11-27 03:09:09 <gmaxwell> Because failing every single time is crazy and unlike the behavior for other people.
336 2013-11-27 03:13:18 <edcba> sendmany is using unspent amount as fee ?
337 2013-11-27 03:15:15 <gmaxwell> edcba: can you try asking that again?
338 2013-11-27 03:18:54 <edcba> how the fee is determined with sendmany command ?
339 2013-11-27 03:22:27 <edcba> hmm send gui can add recipients
340 2013-11-27 03:24:15 <edcba> hmm but i can't specify which account
341 2013-11-27 03:25:03 <edcba> why isn't that software simple...
342 2013-11-27 03:25:24 <gmaxwell> The account probably doesn't do anything that you think it does.
343 2013-11-27 03:25:29 <gmaxwell> er account feature.
344 2013-11-27 03:25:50 <edcba> i want to spend from one address
345 2013-11-27 03:25:54 <gmaxwell> edcba: fees are set by using settxfee or by the preference.
346 2013-11-27 03:26:36 <gmaxwell> edcba: you cannot do that in current versions of bitcoin-qt/d (except via using the raw transaction interface), and certantly the accounts system has nothing to do with that.
347 2013-11-27 03:26:48 <edcba> so if i use sendmany i have to do {addr1:25,add2:24.9} if i setted the fee as 0.1 ?
348 2013-11-27 03:27:27 <gmaxwell> Transactions do not have a 'from' there is no way to manually specify which coins you will use with sendmany.
349 2013-11-27 03:27:42 <gmaxwell> The account feature of the rpc is just a bookkeeping feature, primarily intended for shared wallets.
350 2013-11-27 03:27:51 <edcba> fromaccount ?
351 2013-11-27 03:28:11 <edcba> it won't use the addresses of that account ?
352 2013-11-27 03:28:14 <gmaxwell> No.
353 2013-11-27 03:28:19 <edcba> wtf
354 2013-11-27 03:28:30 <edcba> that client is totally misleading
355 2013-11-27 03:28:50 <gmaxwell> Transactions don't have a "from" in any case, you're been confused by things like blockchain.info into having weird expectations.
356 2013-11-27 03:29:08 <edcba> they have inpits
357 2013-11-27 03:29:10 <edcba> inputs
358 2013-11-27 03:29:25 <edcba> how is that different from a "from" ?
359 2013-11-27 03:29:25 <gmaxwell> The account system is _just_ local bookeeping, this is the document, expected, intended behavior.  Its like keeping categories in your checkbook.
360 2013-11-27 03:30:25 <gmaxwell> edcba: it's different from a from because the "prior to" of a coin being spent may not be owned by the person authoring the transaction in question, so if you assume it's a from bad things will occasisonally happen.
361 2013-11-27 03:30:54 <edcba> ok i see
362 2013-11-27 03:30:58 <kjj> If I were god, I'd fire up another universe at the point just before accounts were added to the client.  I'm curious if telling people that accounts will never be added would take more or less time than explaining what they do and don't do
363 2013-11-27 03:31:50 <gmaxwell> kjj: they were basically useful for the first generation of crappy webwallets. ... but yea, I use them myself just to keep notes about transactions, but TBH just some regular note facilities would work just as well.
364 2013-11-27 03:32:13 <gmaxwell> perhaps in a big wallet rewrite we'll remove them.
365 2013-11-27 03:32:20 <kjj> I tried doing that.  ended in a nightmare.
366 2013-11-27 03:32:33 <kjj> the keeping track thing, not the removal thing
367 2013-11-27 03:33:04 <cfields> woohoo, i think
368 2013-11-27 03:33:15 <cfields> 2013-11-27 03:32:45 Corruption: checksum mismatch
369 2013-11-27 03:33:24 <gmaxwell> cfields: woot.
370 2013-11-27 03:33:29 <edcba> you won !
371 2013-11-27 03:33:43 <cfields> i forced it in code, though
372 2013-11-27 03:33:53 <gmaxwell> oh lame.
373 2013-11-27 03:33:58 <cfields> so now i have something to work with
374 2013-11-27 03:34:27 <cfields> gmaxwell: there's a place where there's a time-gap between 2 writes that are read as a whole
375 2013-11-27 03:34:41 <cfields> so i stuck a sleep between em and kill -9'd.
376 2013-11-27 03:34:55 <gmaxwell> oh thats fantastic.
377 2013-11-27 03:35:23 <cfields> so i'm hoping that if i glue em into a single write, there's no chance for corruption
378 2013-11-27 03:35:37 <cfields> *for corruption there
379 2013-11-27 03:35:56 <kjj> not inside a lock?  or does the mac just suck at locking?
380 2013-11-27 03:37:07 <cfields> kjj: current theory i'm running with is that it's a timing issue that's present everywhere, and that timing just happens to vary enough on some macs
381 2013-11-27 03:39:29 <gmaxwell> cfields: even if you make the write a single operation ... the system can tear writes. e.g. imagine the power goes out in the middle of the write.
382 2013-11-27 03:39:42 <gmaxwell> leveldb should still be able to recover in that case, and if it can't that needs to be fixed.
383 2013-11-27 03:39:46 <edcba> depends on size usually
384 2013-11-27 03:40:05 <gmaxwell> (e.g. it should just back out the last transaction if it can't be fully applied)
385 2013-11-27 03:40:38 <edcba> ok let's state differently my problem : how do i issue a transaction to multiple recipients from a specified address ? :)
386 2013-11-27 03:40:55 <kjj> there is no from
387 2013-11-27 03:41:11 <gmaxwell> edcba: you use another procol than bitcoin, maybe visa or paypal? something with a from. :P
388 2013-11-27 03:41:11 <kjj> but you can use sendmany or createrawtransaction
389 2013-11-27 03:41:19 <cfields> gmaxwell: i'm thinking that our use of using the leveldb checksum might be breaking that journaling
390 2013-11-27 03:41:53 <gmaxwell> edcba: if you ask a different question: how can you spend specific coins: use bitcoin-qt git which has coin control, or use createrawtransaction but be very careful with createraw.
391 2013-11-27 03:41:55 <cfields> gmaxwell: meaning: if the checksum wasn't checked, it'd roll back and continue. but checksum is checked, doesn't match, bails
392 2013-11-27 03:42:36 <cfields> i have nothing to back that up ofcourse :)
393 2013-11-27 03:42:40 <cfields> just something i'm poking at
394 2013-11-27 03:42:48 <gmaxwell> cfields: uh. I think in that case where its the last transaction and it can just be rolled back.... we really want to only log something and not fail. :P
395 2013-11-27 03:44:37 <cfields> gmaxwell: for sure. just a hunch that there may be a bug in that path, since checsumming is defaulted off
396 2013-11-27 03:45:01 <gmaxwell> yea, not an awful guess.
397 2013-11-27 03:45:23 <edcba> kjj: how can i use sendmany if i can only specify an account and not an address ?
398 2013-11-27 03:47:30 <kjj> I'm not sure I understand the question.  you just specify the account, or the default account
399 2013-11-27 03:50:07 <edcba> so if i want to spend addr 1ZZZ i have to setaccount 1ZZZ bla then sendmany bla {1aaa:25,1bbb:25} ?
400 2013-11-27 03:50:26 <kjj> no, you need to stop thinking of addresses as things that you spend from
401 2013-11-27 03:50:33 <edcba> why ?
402 2013-11-27 03:50:35 <kjj> addresses are for receiving only
403 2013-11-27 03:50:51 <kjj> because that's how bitcoin works
404 2013-11-27 03:50:55 <edcba> but then when it's received i want to start from that
405 2013-11-27 03:51:14 <edcba> and not let bitcoin decide how it mess up privacy
406 2013-11-27 03:51:38 <kjj> if you want to spend a specific transaction, you need to use the raw transaction API
407 2013-11-27 03:52:31 <edcba> ok so accounts are really useless
408 2013-11-27 03:52:50 <edcba> and api is quite bad
409 2013-11-27 03:52:59 <kjj> yes, and yes
410 2013-11-27 03:55:00 <gmaxwell> Accounts have their use, it's not very interesting, its not what you want them to do. What they actually do is documented, but you're insisting on them imagining that they do something they don't.
411 2013-11-27 03:59:23 <edcba> the problem is api makes you think otherwise
412 2013-11-27 03:59:56 <jrmithdobbs> No it doesn't
413 2013-11-27 04:00:32 <jrmithdobbs> You inferred something through a misunderstanding of the overall system that was incorrect and not based on reality
414 2013-11-27 04:00:39 <andytoshi> jrmithdobbs: i think it does, accounts appear to "contain" addresses somehow
415 2013-11-27 04:01:04 <jrmithdobbs> It is a convoluted metaphor though
416 2013-11-27 04:01:07 <kjj> meh.  go easy on him.  it isn't like he's the first to run into this.  there are a hundred threads on the forum with pretty much this exact conversation
417 2013-11-27 04:01:16 <andytoshi> maybe i'm wrong, i haven't looked at the qt gui in a while..
418 2013-11-27 04:01:17 <gmaxwell> edcba: it does today, but mostly only because bc.i has ingraned in people's mind that transactions have "from"s.
419 2013-11-27 04:01:30 <gmaxwell> Back when the api was written no one at all was thinking in that manner.
420 2013-11-27 04:01:38 <andytoshi> but it should definitely describe accounts as "tracking" addresses as opposed to being a collection of them..
421 2013-11-27 04:02:04 <gmaxwell> nothing in the reference software suggests or shows any from on a transaction, excepting the raw transaction api, which also was added much later.
422 2013-11-27 04:02:18 <gmaxwell> andytoshi: there are no accounts in the GUI at all. It's an rpc only feature.
423 2013-11-27 04:02:18 <jrmithdobbs> Addresses aren't supposed to be reused. With that in mind what you just said doesn't make much sense
424 2013-11-27 04:02:31 <andytoshi> ah
425 2013-11-27 04:02:36 <kjj> yeah, the raw transaction API is when my personal attempt to use accounts for tracking went to shit
426 2013-11-27 04:02:42 <gmaxwell> It's observably confusing now, but it really wasn't when it was created. People's context changed.
427 2013-11-27 04:02:48 <gmaxwell> We never had questions like these in 2011.
428 2013-11-27 04:03:01 <jrmithdobbs> Ya
429 2013-11-27 04:03:22 <jrmithdobbs> It's a poor design in hindsight but it did actually make sense
430 2013-11-27 04:03:26 <gmaxwell> at some point I expect us to just remove the functionality and replace it with a more generic labels/notes stuff.
431 2013-11-27 04:03:48 <gmaxwell> And also multiple wallet support, which will actually accomplish what people trying to do "from" stuff for privacy want.
432 2013-11-27 04:03:53 <gmaxwell> (plus we have coin control now)
433 2013-11-27 04:03:58 <kjj> heh.  want a patch that adds "ACCOUNTS DON'T WORK LIKE THAT" to the help RPC listing?
434 2013-11-27 04:04:05 <gmaxwell> plus the spread of coinjoin will make needing to do coincontrol for privacy less important.
435 2013-11-27 04:04:52 <BCB> not this conversation again!
436 2013-11-27 04:04:57 <edcba> sorry !
437 2013-11-27 04:05:08 <andytoshi> kjj: this might be worth doing actually..
438 2013-11-27 04:05:53 <andytoshi> put a flag on the first use of sendfrom or something
439 2013-11-27 04:05:58 <gmaxwell> ugh.
440 2013-11-27 04:06:00 <edcba> maybe an online documentation explaining very precisely that stuff and a link on help :)
441 2013-11-27 04:06:04 <gmaxwell> no statfulness in an rpc.
442 2013-11-27 04:06:06 <andytoshi> lol
443 2013-11-27 04:06:10 <BCB> edcba: ++
444 2013-11-27 04:06:18 <andytoshi> yeah, that's a good point gmaxwell
445 2013-11-27 04:06:20 <gmaxwell> edcba: you too can write documentation. :)
446 2013-11-27 04:06:24 <kjj> so, I use "getnewaddress p2pool" now and then to rotate my p2pool addresses.  then, I sometimes gather those semi-dust transactions and send to the same address
447 2013-11-27 04:06:31 <BCB> gmaxwell: not if you don't understand it
448 2013-11-27 04:06:39 <gmaxwell> BCB: he almost does.
449 2013-11-27 04:06:40 <gmaxwell> :P
450 2013-11-27 04:06:51 <kjj> oops.  raw transactions come from '', and get counted twice in the p2pool account
451 2013-11-27 04:06:52 <BCB> gmaxwell: i don't :(
452 2013-11-27 04:07:19 <andytoshi> we could add an unconditional help message on listreceivedbyaddress
453 2013-11-27 04:07:30 <andytoshi> saying "try listunspent" to see the actual coins
454 2013-11-27 04:07:40 <andytoshi> that at least would get people asking the right questions
455 2013-11-27 04:07:42 <kjj> now my '' account has negative hundreds of bitcoins and it just isn't worth attempting to unscrew it
456 2013-11-27 04:07:50 <gmaxwell> kjj: move!
457 2013-11-27 04:07:59 <kjj> yeah, my dust collector does that now
458 2013-11-27 04:08:06 <ido> anyone mining bitcoin with a stratix fpga right now?
459 2013-11-27 04:08:14 <ido> stratix 4 or 5?
460 2013-11-27 04:08:26 <kjj> so it isn't getting worse over time any more.  but it was easier to just stop keeping track than it was to fix
461 2013-11-27 04:08:58 <kjj> by the way, motherboard makers can die in a fire
462 2013-11-27 04:16:49 <kjj> I can just see some engineer in Korea thinking "We only need to check the PCIEx16 slots for VGA cards.  No one is ever going to want to use the fast slots for SAS cards and put their token VGA card in the x1 slot..."
463 2013-11-27 04:17:38 <andytoshi> lol, more like "we only need to do a boot check on the systems that dell and emachines are selling"
464 2013-11-27 04:50:59 <abc4btc> join #mining.bitcoin.cz
465 2013-11-27 04:51:13 <abc4btc> oops : )
466 2013-11-27 05:14:22 <helo> it would be nice during -reindex from a trusted copied ~/.bitcoin i could tell it to not bother with validation
467 2013-11-27 05:14:54 <helo> my poor slow offline netbook is sloooow
468 2013-11-27 05:15:36 <kjj> that is one thing I miss from the pre-0.8 days
469 2013-11-27 05:17:29 <andytoshi> helo: i bet there's a single function in the source you could set to a no-op and compile a bitcoind-promiscuous
470 2013-11-27 05:17:53 <helo> it's almost enough to get me to unlock my locked wallet on my net-connected machine
471 2013-11-27 05:17:56 <helo> but not quite
472 2013-11-27 05:19:08 <Auctus> if my blockchain is 2 years out of date, i should be able to check balances of 3 year old addresses right?
473 2013-11-27 05:19:13 <kjj> -checklevel=0
474 2013-11-27 05:19:37 <kjj> addresses don't have balances.
475 2013-11-27 05:19:49 <kjj> you can see transactions, but you won't know if they've been later redeemed or not
476 2013-11-27 05:20:35 <Auctus> how does blockchain.info determine balance? https://blockchain.info/address/198aMn6ZYAczwrE5NvNTUMyJ5qkfy4g3Hi
477 2013-11-27 05:20:41 <gmaxwell> kjj: checklevel=0 won't have that effect.
478 2013-11-27 05:20:56 <kjj> yeah, but it's the best you can do without hacking it up
479 2013-11-27 05:21:02 <gmaxwell> Auctus: it evaluates the whole blockchain and produces a large additional database of balances.
480 2013-11-27 05:21:10 <Auctus> ahh i see.
481 2013-11-27 05:21:16 <gmaxwell> kjj: It won't actually change the reindex behavior at all though.
482 2013-11-27 05:21:36 <kjj> oh, that's only for already indexed stuff
483 2013-11-27 05:21:44 <gmaxwell> it's only for the on startup test.
484 2013-11-27 05:21:55 <gmaxwell> helo: if you're copying from a trusted system why not copy the indexes too?
485 2013-11-27 05:23:48 <helo> afaik i did... just copied ~/.bitcoin entirely
486 2013-11-27 05:25:31 <gmaxwell> helo: and it made you reindex?
487 2013-11-27 05:25:33 <gmaxwell> What kind of systems were you copying between?
488 2013-11-27 05:26:01 <helo> x86_64 to i386
489 2013-11-27 05:26:16 <gmaxwell> ah, okay.
490 2013-11-27 05:26:23 <arioBarzan> if my node is not completely synced new blocks yet, could I sendrawtransaction a coin which is not yet in my database?
491 2013-11-27 05:26:34 <kjj> yes
492 2013-11-27 05:26:38 <gmaxwell> No.
493 2013-11-27 05:26:49 <gmaxwell> Your node won't forward it because it can't validate the inputs.
494 2013-11-27 05:27:04 <helo> it can be in your database if the tx is in your wallet.dat though, right?
495 2013-11-27 05:27:08 <gmaxwell> (the sendrawtransaction will just reject)
496 2013-11-27 05:27:35 <helo> i guess it would be a 0-confirm input, which i guess is rejected
497 2013-11-27 05:28:18 <kjj> that's lame.
498 2013-11-27 05:28:20 <arioBarzan> gmaxwell: I get error: {"code":-22,"message":"TX rejected"} . so that is the reason?
499 2013-11-27 05:28:29 <gmaxwell> arioBarzan: yes.
500 2013-11-27 05:28:45 <gmaxwell> arioBarzan: you can just go use http://eligius.st/~wizkid057/newstats/pushtxn.php to submit
501 2013-11-27 05:28:54 <arioBarzan> tnx
502 2013-11-27 05:43:34 <Auctus> what can the bitcoin api tell me about addresses not in my wallet? Anything? Can I tell # of transactions?
503 2013-11-27 05:44:39 <gmaxwell> Auctus: things like # of transactions requires a large additional index which bitcoind doesn't keep. (and, besides, with proper use the number should be 0, 1 or 2.. not very interesting)
504 2013-11-27 05:48:42 <arioBarzan> how little of an output leads to tx considered as dust?
505 2013-11-27 05:51:18 <wumpus> arioBarzan: less than 54 uBTC is considered dust
506 2013-11-27 05:51:43 <wumpus> 54.60 even
507 2013-11-27 05:52:15 <Auctus> so ~5 us cents at the current exchange rate?
508 2013-11-27 05:53:28 <wumpus> yes
509 2013-11-27 05:56:37 <wumpus> but changes to that logic are underway
510 2013-11-27 05:59:23 <gmaxwell> wumpus: hm. I hadn't considered that changing the relay level would change that. I suppose its fine, but I forgot we'd linked it.
511 2013-11-27 06:00:26 <wumpus> gmaxwell: yes it caught me unaware too how things were linked
512 2013-11-27 06:01:02 <wumpus> are linked*
513 2013-11-27 06:01:23 <gmaxwell> it was intentional, the "if the value changes, this knob will be changed, thus all the other stuff that should depend on the value"
514 2013-11-27 06:01:27 <gmaxwell> but yea, easy to forget.
515 2013-11-27 06:04:04 <wumpus> yes it makes sense, although it also means not having to explicitly think about the other values when they change
516 2013-11-27 06:04:31 <wumpus> and  that it's not visible in the commit directly, though the tests help there
517 2013-11-27 06:43:31 <nanotube> <gmaxwell> wumpus: hm. I hadn't considered that changing the relay level would change that. I suppose its fine, but I forgot we'd linked it. <- and that's why we invented comments. :)
518 2013-11-27 06:46:19 <wumpus> comments could help, but as they are not validated by the compiler, there are even indications that they can cause bugs because people forget to update them and thus make wrong assumptions
519 2013-11-27 06:56:55 <gmaxwell> A /*Remember other value dependant things are based on this setting:*/ wouldn't hurt.
520 2013-11-27 06:57:01 <gmaxwell> beyond that there is grep. :P
521 2013-11-27 07:23:45 <diki> Are there any good hosts that accept Bitcoin?
522 2013-11-27 07:25:02 <gmaxwell> wtf: see issue #2785
523 2013-11-27 07:25:10 <gmaxwell> 1) Go to system preferences and click on Date/Time. Set the date to 2012. Close System preferences and hit save. Open Bitcoin-qt and get the corrupted database message. Click abort.
524 2013-11-27 07:25:10 <gmaxwell> I don't have the skills to fix this but I can recreate the problem.
525 2013-11-27 07:25:14 <gmaxwell> 2) Set system preferences and click set date and time automatically. Open Bitcoin-qt and the database is fine.
526 2013-11-27 07:25:17 <gmaxwell> Can you use an atomic clock API and rely on that instead of the system clock to prevent leveldb from becoming corrupted?
527 2013-11-27 07:28:03 <wumpus> I was baffled too when I read it
528 2013-11-27 07:28:40 <wumpus> this is likely a different issue, I remember an issue from diapolo about crashes with very wrong system time
529 2013-11-27 07:29:00 <wumpus> https://github.com/bitcoin/bitcoin/issues/2007
530 2013-11-27 07:38:26 <cfields> I can confirm as well, but...
531 2013-11-27 07:38:44 <cfields> "CheckBlock() : block timestamp too far in the future"
532 2013-11-27 07:39:39 <cfields> so, unrelated to any real corruption
533 2013-11-27 07:47:19 <wumpus> that's exactly the error in the issue I quoted cfields
534 2013-11-27 07:47:30 <wumpus> it's not mac related, happens also on windows (and linux probably)
535 2013-11-27 07:49:16 <cfields> wumpus: ah sorry, i was looking at #2785. Seems they're mixing issues in that bug
536 2013-11-27 07:49:41 <wumpus> I know, just replied there
537 2013-11-27 07:52:52 <wumpus> would have been interesting though if all the "corruption" issues were caused by wrong system time
538 2013-11-27 07:53:23 <cfields> i'd be pretty pissed, it distracted me all day today :)
539 2013-11-27 07:53:36 <gmaxwell> wumpus: I'm pretty sure that not all corruption were, but perhaps the corruption that goes away ones were.
540 2013-11-27 07:53:42 <wumpus> the great macos clock bug
541 2013-11-27 07:54:15 <cfields> it's worth noting, though...
542 2013-11-27 07:54:27 <gmaxwell> probably we should add some check that checks to see if the latest accepted block, in the index, is too far into the future and puts up some "your clock is fucked up" message.
543 2013-11-27 07:54:45 <cfields> before it showed the corrupt db error, it said "your clock is way off, you should really fix that"
544 2013-11-27 07:54:47 <wumpus> could explain some cases, though the OP in https://github.com/bitcoin/bitcoin/issues/2785 doesn't have the Future message
545 2013-11-27 07:55:38 <cfields> gmaxwell: in my cast anyway, i got exactly that
546 2013-11-27 07:55:46 <cfields> *my case.
547 2013-11-27 07:55:55 <cfields> jeez, my fingers have given up for the day
548 2013-11-27 08:20:52 <topi`> about MultiBit, as far as I see it's written in java - would that mean it's possible to run on big-endian archs (like my iMac G5)?
549 2013-11-27 08:21:24 <bitanarchy> does openpaperwallet have a better randomizer than bitaddress?
550 2013-11-27 08:21:43 <topi`> I know some code in bitcoin-qt limits it to little-endian cpus
551 2013-11-27 08:31:47 <topace_> anything weird going on? just started getting safe mode warnings from a few bitcoind's
552 2013-11-27 08:35:23 <gmaxwell> topace_: please grep -i invalid ~/.bitcoin/debug.log and pastebin the results.
553 2013-11-27 08:37:12 <gmaxwell> ;;bc,blocks
554 2013-11-27 08:37:13 <gribble> 271740
555 2013-11-27 08:38:08 <gmaxwell> my nodes are okay, and restart okay.
556 2013-11-27 08:39:33 <_ingsoc> Is there a wishlist of things people want in bitcoind and bitcoin-qt that aren't implemented yet / no plans to do so currently?
557 2013-11-27 08:41:24 <mappum> if anyone has some spare brainspace, it would be great if i could get some feedback on my altcoin proposal (it's not just another clone). https://bitcointalk.org/index.php?topic=348561.0
558 2013-11-27 08:41:59 <swulf--> hly hell mappum
559 2013-11-27 08:42:03 <swulf--> I was just working on a similar document
560 2013-11-27 08:42:07 <mappum> D:;
561 2013-11-27 08:42:14 <nsh> what is the point of the "proposal" bit?
562 2013-11-27 08:42:27 <mappum> just to indicate that it isn't implemented or final yet
563 2013-11-27 08:42:35 <nsh> why don't you just make it, then demonstrate that it does cool things?
564 2013-11-27 08:42:56 <mappum> i wanted to see if people called out any big fundamental problems first
565 2013-11-27 08:43:00 <mappum> this will take a while to make
566 2013-11-27 08:43:04 <swulf--> there is a big fundamental problem
567 2013-11-27 08:43:43 <nsh> i would still recommend trying to do mathematics and even if you fail you will have learned more than you could ever do by talking about hypothetical mathematics :)
568 2013-11-27 08:44:08 <nsh> but then i know nothing
569 2013-11-27 08:44:34 <mappum> true, i will probably start working on it after i'm a little more confident i'm making the right design choices
570 2013-11-27 08:44:37 <mappum> swulf--: what'
571 2013-11-27 08:44:40 <mappum> s the problem?
572 2013-11-27 08:44:53 <swulf--> mappum: your system doesn't include any distributed proof of possession
573 2013-11-27 08:45:23 <swulf--> i'll be releasing my document, which is essentially the exact same project, in a few days
574 2013-11-27 08:45:36 <swulf--> i have to solve one issue first, though
575 2013-11-27 08:45:51 <mappum> it does, when a miner finds a valid block, they will have to include the chunk of data they found the hash with
576 2013-11-27 08:46:09 <topace_> gmaxwell, grepping (huge debug.log)..
577 2013-11-27 08:46:18 <swulf--> mappum: data is stored in your blockchain?
578 2013-11-27 08:46:22 <mappum> nodes can verify its the right data because they know the hash of it
579 2013-11-27 08:46:24 <mappum> no
580 2013-11-27 08:46:43 <swulf--> mappum: how do you verify that a node held onto the data after publishing the hash+block?
581 2013-11-27 08:46:52 <swulf--> you could compute the hash, then delete the data
582 2013-11-27 08:47:07 <swulf--> lemme re-read your doc in detail
583 2013-11-27 08:47:12 <mappum> you don't, they could do that if they wanted to. but then they have less hashing power
584 2013-11-27 08:47:29 <topace_> http://pastebin.com/BmXy7GmN
585 2013-11-27 08:48:17 <mappum> swulf--: what's the problem you need to solve with yours?
586 2013-11-27 08:48:18 <gmaxwell> topace_: okay my node has happily accepted those blocks
587 2013-11-27 08:48:47 <gmaxwell> topace_: can you grep -A 3 -B 3 Invalid ~/.bitcoin/debug.log   (this one will run faster since its not insensitive)
588 2013-11-27 08:49:33 <swulf--> mappum: OK, your document relies on miners constantly hashing the stored data chunks, but that's a problem because hashing gigs of data is time consuming.
589 2013-11-27 08:49:50 <swulf--> the other problem is validation: do all other mines have to store the data in order to verify that the hash is correct?
590 2013-11-27 08:50:29 <topace_> http://pastebin.com/y96wz0Ji
591 2013-11-27 08:50:54 <swulf--> the problem with my current white paper is that the validation is too large (~16KB per 1MB storage block, which is about 15KB larger than I need)
592 2013-11-27 08:51:05 <swulf--> err want
593 2013-11-27 08:54:17 <mappum> swulf--: nodes don't have to store the data to verify it, the miner just includes that piece of the data in the block
594 2013-11-27 08:54:26 <mappum> so pieces will need to be small obviously
595 2013-11-27 08:54:58 <mappum> but only one proof-of-whatever has to be verified per block so it isn't too much overhead
596 2013-11-27 08:55:27 <swulf--> I'm confused - if the network is storing 1TB of data, how, after say 10000 blocks can you be sure a chunk still exists?
597 2013-11-27 08:56:25 <mappum> you can't, but the fact that miners have a higher hashrate if they keep it means at least some miners will probably have it
598 2013-11-27 08:57:27 <mappum> there's a very small chance all miners in the world will blacklist your file
599 2013-11-27 08:58:20 <swulf--> I'll post my whitepaper soon and I'd like to get your feedback on it. We could work together to come up with something good
600 2013-11-27 08:58:40 <mappum> cool, i'm looking forward to that
601 2013-11-27 08:58:52 <mappum> i think this is an inevitable thing to be made
602 2013-11-27 08:59:05 <mappum> and the existing Datacoin is a terrible solution
603 2013-11-27 08:59:14 <topace_> gmaxwell, any idea? I'm running --reindex now
604 2013-11-27 08:59:29 <swulf--> I think so too
605 2013-11-27 08:59:40 <swulf--> I was just gonna start developing it thinking I'd have time, but it looks like others are already starting on it
606 2013-11-27 08:59:48 <swulf--> so I should just publish the specs and see what people thing.
607 2013-11-27 08:59:51 <swulf--> think*
608 2013-11-27 09:00:01 <gmaxwell> topace_: looks like you had a corrupted chainstate, the reindex will fix it. What OS and what versions of things are you running?
609 2013-11-27 09:00:37 <topace_> linux official binaries 0.8.5
610 2013-11-27 09:01:16 <topace_> on ubuntu-server 12.04.3
611 2013-11-27 09:02:06 <mappum> swulf--: how does yours work?
612 2013-11-27 09:02:34 <swulf--> Not allowed to say just yet, but it's a very similar premise as yours but with trust-less 99.999% data storage guarantee
613 2013-11-27 09:02:59 <swulf--> and miner "power" is derived the same as bitcoin/litecoin
614 2013-11-27 09:03:53 <mappum> so when do miners prove they are storing something?
615 2013-11-27 09:04:11 <swulf--> monthl
616 2013-11-27 09:04:13 <swulf--> monthly
617 2013-11-27 09:04:48 <mappum> well where in the system do they prove it?
618 2013-11-27 09:04:57 <swulf--> or rather, every block-month (roughly 10 mins * 6 blocks/hr * 24 hrs/day * 7 days/wk * 4 wks/month blocks)
619 2013-11-27 09:05:06 <swulf--> they just "announce" it, and if they don't, they don't get paid
620 2013-11-27 09:05:55 <mappum> so each block has a bunch of transactions that come from miners announcing their stored stuff?
621 2013-11-27 09:06:11 <swulf--> that's part of it, yeah
622 2013-11-27 09:06:15 <swulf--> the devils in the details though
623 2013-11-27 09:06:25 <mappum> interesting
624 2013-11-27 09:06:40 <swulf--> fine i'll try and wrap up the document today, haha.
625 2013-11-27 09:06:52 <swulf--> i'll leave my problem as "open" and see if anyone has ideas.. I've been stumped for a week
626 2013-11-27 09:07:02 <mappum> sweet
627 2013-11-27 09:08:23 <swulf--> the problem is that miners have to prove they have data, which the current description requires something like a 16KB transaction, which is size-prohibitive when you consider all the data on the network. i believe it can be done <256 bytes, but not entirely sure. my crypto math isn't top-notch
628 2013-11-27 09:11:09 <mappum> so what's in the 16kb transaction
629 2013-11-27 09:11:26 <swulf--> proof of possession
630 2013-11-27 09:11:37 <mappum> i mean on a technical level
631 2013-11-27 09:11:45 <mappum> why does the proof take so much space?
632 2013-11-27 09:12:12 <swulf--> because normally proof of posession requires the "client" to store some metadata to verify possession
633 2013-11-27 09:12:27 <swulf--> to do it distributedly, you have to announce some piece of the data that others can verify
634 2013-11-27 09:13:15 <mappum> ah, i see
635 2013-11-27 09:16:09 <topace_> gmaxwell, is this possibly the "Random blockchain corruption bug" that usually affects mac os?
636 2013-11-27 09:16:35 <gmaxwell> topace_: Unlikely.
637 2013-11-27 09:16:47 <gmaxwell> mappum: your proof system is trivally gamable.
638 2013-11-27 09:16:59 <mappum> how so?
639 2013-11-27 09:17:13 <gmaxwell> mappum: I just keep one piece of data, instead of all of it, then I rapidly iterate the work function until I get work which would select that data.
640 2013-11-27 09:17:25 <gmaxwell> so it allows a hashrate computation trade off.
641 2013-11-27 09:17:26 <mappum> did you read all of it? it specifically combats that
642 2013-11-27 09:17:40 <topace_> still reindexing gonna be a while.. at  ~212000
643 2013-11-27 09:18:24 <gmaxwell> mappum: it still enables a tradeoff regardless of how expensive it is. Perhaps the tradeoff doesn't win, but I'm skeptical, e.g. as soon as you get someone with a workfunction asic.
644 2013-11-27 09:19:04 <mappum> then i suppose it's beneficial to use scrypt, or maybe something more specifically suited to this
645 2013-11-27 09:19:52 <mappum> and as long as the tradeoff is ok for most of the miners, it should be OK
646 2013-11-27 09:20:28 <mappum> i can't imagine the tradeoff being better that way, even with ASICs though
647 2013-11-27 09:20:58 <mappum> since that function needs to take a long time, it can be designed to be super asic unfriendly
648 2013-11-27 09:22:13 <gmaxwell> "Chunk sizes would need to stay small since all nodes will need a copy of the chunk data to verify the proof-of-stock"
649 2013-11-27 09:22:25 <gmaxwell> you could easily engineer around this.
650 2013-11-27 09:23:05 <gmaxwell> the other problem, incidentally, with your POW is that the storage is outsourceable.
651 2013-11-27 09:23:46 <gmaxwell> e.g. you do work work and ask someone to give you the chunk result.
652 2013-11-27 09:24:49 <mappum> interesting point, i hadn't thought about that too much
653 2013-11-27 09:25:46 <gmaxwell> mappum: amiller has been killing himself trying to come up with ways to make mining non-outsourcable non-hostable in practice.
654 2013-11-27 09:25:48 <mappum> maybe don't have a nonce in the work hash and make the timestamp only update every minute or something
655 2013-11-27 09:26:19 <gmaxwell> WRT your goals my recommendation is that your "PoW" be a proof of disk throughput instead. Then the lookup can't be outsourced without outsourcing the expensive mining setup.
656 2013-11-27 09:26:35 <gmaxwell> (and amillier has some proposals to make cloud mining insecure)
657 2013-11-27 09:28:08 <nsh> can you prove decentralization itself directly somehow?
658 2013-11-27 09:28:16 <nsh> (systemically)
659 2013-11-27 09:28:40 <mappum> but then it would be hard to verify miners are storing the data without everyone keeping a lot of data
660 2013-11-27 09:29:27 <nsh> with a crypographic transport layer you could probably demonstrate proportionality of computation to network traversal
661 2013-11-27 09:29:37 <nsh> which would weakly indicate decentralization
662 2013-11-27 09:30:16 <gmaxwell> mappum: thats not so.
663 2013-11-27 09:30:46 <mappum> i suppose there is some crypto that does this that i don't know about
664 2013-11-27 09:31:01 <mappum> how do you verify storage of data without people needing copies of it?
665 2013-11-27 09:31:01 <swulf--> There is! I reference it in my design
666 2013-11-27 09:31:16 <gmaxwell> by using a hash tree.
667 2013-11-27 09:31:21 <gmaxwell> same way SPV mode works.
668 2013-11-27 09:31:25 <mappum> i thought you said that was the problem you need to solve
669 2013-11-27 09:31:37 <swulf--> a hash tree isn't complete, you can't just gaurantee a player hasn't stored the hash tree and thrown away the data
670 2013-11-27 09:31:56 <swulf--> mappum: I have that problem solved. I just need to reduce the bandwidth requiremen t
671 2013-11-27 09:32:24 <gmaxwell> swulf--: uh... sure you can. it's trivial.
672 2013-11-27 09:32:48 <gmaxwell> swulf--: you have the player disclose the actual stored data chunks, and use the hash tree to prove that its the right data.
673 2013-11-27 09:32:57 <swulf--> I'm curious - how does A have B store data, and B prove to C he has it, without C knowing anything?
674 2013-11-27 09:33:15 <swulf--> gmax: sure, but that only works once (not everyone verifying will want to store that data)
675 2013-11-27 09:33:54 <swulf--> I have a solution that works, but it requires desclosing a small piece of the data (so all computed math can be proven back to a single piece)
676 2013-11-27 09:34:15 <swulf--> basically it's a hash tree (sums of hashes) with a "root" data block being provided
677 2013-11-27 09:34:28 <swulf--> I don't fully understand the math, actually
678 2013-11-27 09:34:32 <swulf--> but it generally makes sense
679 2013-11-27 09:35:20 <mappum> if everyone only has that small piece, doesn't that mean the miner has the same piece and can generate the proof from it?
680 2013-11-27 09:35:50 <swulf--> anyone should be able to validate the proof, yeah
681 2013-11-27 09:36:09 <swulf--> you can't ask everyone to store that small piece though (and most people will try to lie about storing it)
682 2013-11-27 09:36:21 <swulf--> you have to assume nobody is honest about storing your data, they just want your money
683 2013-11-27 09:37:17 <swulf--> I read somewhere that SHA-1 takes 24 seconds on 1MB of data on a modern 3.2ghz cpu
684 2013-11-27 09:37:33 <mappum> i don't think so...
685 2013-11-27 09:37:37 <swulf--> I think it'd be too difficult to build a PoW system that uses the data itself as part of the PoW
686 2013-11-27 09:38:14 <gmaxwell> swulf--: I assume you meant 1GB of data?
687 2013-11-27 09:38:27 <gmaxwell> even that sounds slow.
688 2013-11-27 09:38:28 <swulf--> gmax: yeah, sorry.
689 2013-11-27 09:38:35 <mappum> http://www.cryptopp.com/benchmarks.html
690 2013-11-27 09:38:42 <mappum> 153 MiB / s
691 2013-11-27 09:39:49 <swulf--> still, wouldn't 6 sec/hash be slow when you're trying to find a nonce for a block?
692 2013-11-27 09:40:15 <mappum> so it would still work in my system as long as the time to compute the workhash is > than time to compute one file hash