1 2013-11-20 00:00:24 <sipa> #0
  2 2013-11-20 00:00:37 <sipa> darsie: you can't fork below the last checkpoint
  3 2013-11-20 00:00:47 <darsie> What's a checkpoint?
  4 2013-11-20 00:00:49 <darsie> upgraded at each release?
  5 2013-11-20 00:00:55 <sipa> occassionally
  6 2013-11-20 00:00:58 <sipa> a hardcoded block in the client code
  7 2013-11-20 00:01:01 <darsie> k
  8 2013-11-20 00:01:05 <darsie> k
  9 2013-11-20 00:01:15 <gmaxwell> darsie: just pretend they don't exist.  ... whats you're actual concern there?
 10 2013-11-20 00:01:28 <gmaxwell> (/me anticipates a misunderstanding of the better criteria)
 11 2013-11-20 00:01:42 <darsie> gmaxwell: Just wondering if NSA could invalidate the blockchain by making a new one.
 12 2013-11-20 00:01:57 <sipa> if they actually amass enough power to do so, we have a problem
 13 2013-11-20 00:02:14 <darsie> Like, by outlawing btc, thus reducing mining and then mining themselves.
 14 2013-11-20 00:02:23 <gmaxwell> darsie: If they can outpace the network, and choose to do so, then bitcoin is broken regardless of at what point they diverge from.
 15 2013-11-20 00:02:33 <darsie> yep
 16 2013-11-20 00:03:04 <gmaxwell> In that threat case diverging earlier just makes the attack more expensive, not more powerful.
 17 2013-11-20 00:08:41 <AndyOfiesh> I am trying to find the code that calculates the priority ofa transaction. It's described on the WIKI as this "priority = sum(input_value_in_base_units * input_age)/size_in_bytes". It seems to have been removed, and the min transaction fee has been simplfied a bit. Is there any truth to that? Can I assume that all criteria for determining the minimum fee of a transaction is in GetMinFee() in main.cpp?
 18 2013-11-20 00:09:12 <gmaxwell> AndyOfiesh: no.
 19 2013-11-20 00:10:55 <gmaxwell> AndyOfiesh: search the codebase for dPriority ... also the most recent release and git are different, so look at the one that's applicable to your interest.
 20 2013-11-20 00:12:48 <AndyOfiesh> GMaxwell: Thanks for the pointer. I was off in the wrong part of town. I see what I need wallet.cpp now.
 21 2013-11-20 00:12:51 <Luke-Jr> AndyOfiesh: inevitably, priority is a miner-chosen thing. the fact that bitcoind has code for it at all is essentially a flaw because we haven't abstracted it out yet
 22 2013-11-20 00:13:20 <gmaxwell> Luke-Jr: it's still useful for realying too.
 23 2013-11-20 00:13:28 <gmaxwell> to prevent denial of service.
 24 2013-11-20 00:14:30 <Luke-Jr> gmaxwell: relay nodes should be prioritising per-node too :P
 25 2013-11-20 00:15:08 <gmaxwell> Luke-Jr: maybe.
 26 2013-11-20 00:31:54 <grubles> can bitcoin-qt be compiled on ppc?
 27 2013-11-20 00:32:00 <grubles> using debian
 28 2013-11-20 00:32:52 <Luke-Jr> no
 29 2013-11-20 00:34:24 <grubles> shucks
 30 2013-11-20 00:34:57 <grubles> Im moderately disappointed
 31 2013-11-20 00:52:43 <gmaxwell> grubles: it can be _compiled_ and it links, but it will not run.
 32 2013-11-20 00:53:32 <super3> how does bitcoin-qt generate the percentage indication for syncing?
 33 2013-11-20 00:54:25 <gmaxwell> super3: it's an estimate based on an assumption of transactions per second and the current date and the date and transactions synced so far.
 34 2013-11-20 00:55:34 <grubles> gmaxwell, thanks
 35 2013-11-20 00:56:14 <super3> gmaxwell, ok. could you point me to a source file for that?
 36 2013-11-20 00:58:27 <gmaxwell> super3: GuessVerificationProgress in checkpoints.cpp
 37 2013-11-20 01:00:23 <super3> gmaxwell, why not just ask another node for an estimate block count?
 38 2013-11-20 01:00:37 <sipa> we do
 39 2013-11-20 01:01:08 <sipa> but blocks are not an accurate proxy for verufication speed
 40 2013-11-20 01:01:33 <gmaxwell> super3: and blockcount is not an accurate proxy for verification work, and peers can just lie.
 41 2013-11-20 01:02:15 <super3> gmaxwell, fair enough. my real goal is a little outside the qt client. I was just trying to see how the qt does it.
 42 2013-11-20 01:02:31 <Jason> /1/3
 43 2013-11-20 01:03:55 <super3> gmaxwell, looking at creating better rpc tools. have to sync my bitcoind for a testing node and using ssh only, so i was thinking of making a simple script to see the percentage of blocks downloaded
 44 2013-11-20 01:04:22 <super3> probably going to use https://blockexplorer.com/q/getblockcount, but wanted to see if there was a way i could do it without relying on a service
 45 2013-11-20 01:04:34 <super3> well an "easy" way
 46 2013-11-20 01:05:13 <super3> but thanks for the insight
 47 2013-11-20 01:07:17 <imton> how could i debug why my test net client is not receiving any tx?
 48 2013-11-20 01:40:19 <cryptic> oh thank god
 49 2013-11-20 01:41:01 <cryptic> it seems like bitcoin is a generalization of paxos
 50 2013-11-20 01:42:47 <sipa> hmm, not really
 51 2013-11-20 01:43:02 <sipa> butcoin does not have a globally consistent state
 52 2013-11-20 01:43:08 <sipa> *bitcoin
 53 2013-11-20 01:43:44 <cryptic> that's why I said a generalization
 54 2013-11-20 03:54:18 <Ryan52> warren: took home an iMac today :)
 55 2013-11-20 04:11:09 <warren> Ryan52: it's possible the time machine guess was wrong
 56 2013-11-20 04:28:06 <nadio> Hello could anyone here help me with bitcoind ?
 57 2013-11-20 04:28:20 <nadio> I am trying to get account address with getaccount
 58 2013-11-20 04:28:42 <Tabaza> اه
 59 2013-11-20 04:28:45 <Tabaza> hi
 60 2013-11-20 04:44:34 <Tabaza> any developers for bitcoins around?
 61 2013-11-20 04:44:51 <Tabaza> i need to hire some professionals for certain projects
 62 2013-11-20 04:51:38 <beethoven8201> MagicalTux: did you roll back trades?
 63 2013-11-20 05:23:32 <phungus> <MagicalTux> very large sell order matching too many buy orders, causing the security system to stop the trade and rollback anything that was caused by it
 64 2013-11-20 06:01:04 <Wild0wnes> hey i've been out of the loop today... are confirmations for bitcoin slowed down today?
 65 2013-11-20 06:01:45 <Wild0wnes> blockchain.info is telling me 15 hours estimated confirmation time... and i included .0005 fee
 66 2013-11-20 06:03:20 <Wild0wnes> nevermind
 67 2013-11-20 06:03:30 <Wild0wnes> guess blockchain is just a bad guesser
 68 2013-11-20 06:14:00 <SomeoneWeird> Wild0wnes, everything is just a guess :)
 69 2013-11-20 06:14:22 <Wild0wnes> indeed
 70 2013-11-20 06:14:27 <Wild0wnes> thx
 71 2013-11-20 06:16:09 <Ryan52> warren: so I've heard. what do we know about SSD versus SATA? (might be a stretch, but I noticed some mention of SSD in the BR)
 72 2013-11-20 06:16:31 <Ryan52> I guess SSDs use SATA too.. what do you call a not-SSD?
 73 2013-11-20 06:24:29 <warren> Ryan52: I think both hard drives and SSD's have the same issue
 74 2013-11-20 06:26:33 <Ryan52> warren: hm, okay, thanks.. since SSD implementation is so recent, and the fsync details mentioned that is the disks responsibility to handle it at that point, made me wonder, just a though.
 75 2013-11-20 06:26:37 <Ryan52> *thought
 76 2013-11-20 06:26:51 <Emcy> i think some of those ssds use mPCIe
 77 2013-11-20 06:27:49 <warren> that's officially called mSATA I think
 78 2013-11-20 06:28:05 <warren> I had a hard time finding an upgrade for my 1.8" SSD drive (they stopped making them)
 79 2013-11-20 06:28:07 <Emcy> no theyre different
 80 2013-11-20 06:28:10 <warren> oh?
 81 2013-11-20 06:28:11 <warren> hm
 82 2013-11-20 06:28:28 <Emcy> same socket but the pinout is different
 83 2013-11-20 06:28:37 <warren> mSATA is the same pins as mini PCIe but not compatible
 84 2013-11-20 06:28:56 <warren> I found an adapter for 1.8" SATA -> mSATA and it worked great for my Thinkpad T410s
 85 2013-11-20 06:32:23 <Emcy> or they might be using the new intel socket now
 86 2013-11-20 06:32:26 <Emcy> NGE or something
 87 2013-11-20 06:35:55 <warren> so many standards
 88 2013-11-20 06:41:56 <Emcy> dont forget half length vs full length cards
 89 2013-11-20 06:42:05 <Emcy> and the half length isnt even a standard
 90 2013-11-20 06:42:36 <Emcy> and sata 4 is moving to pci bus anyway, like everything else in a pc now
 91 2013-11-20 06:43:46 <Emcy> pcs certainly seemt o be becmoing less modular
 92 2013-11-20 06:45:57 <Emcy> the northbridge merged into the chip and southbridge is next, gfx is merging too. Its like theyre becoming monolithic socs with the pci bus hanging off it
 93 2013-11-20 07:53:55 <jgarzik> word
 94 2013-11-20 07:57:01 <Luke-Jr> hey jgarzik
 95 2013-11-20 08:10:39 <Belxjander> herya jgarzik && Luke-Jr
 96 2013-11-20 08:29:31 <tiyoT> hi
 97 2013-11-20 08:29:40 <tiyoT> quick question, its been almost an hour, but my btc transaction still UNconfirmed, my other smaller transaction got confirmed already.
 98 2013-11-20 08:30:47 <Luke-Jr> tiyoT: if you care about confirmation time, pay a fee
 99 2013-11-20 08:31:57 <tiyoT> Luke-Jr: lets use this chan, does bigger btc has slower confirmation rate? my 0.1 already got 4confirmation, my 43 btc is unconfirmed
100 2013-11-20 08:32:18 <tiyoT> Luke-Jr: thanks for the BPM (redfury) support on 3.6.0 btw :)
101 2013-11-20 08:32:20 <Luke-Jr> tiyoT: bigger data size, not value
102 2013-11-20 08:32:57 <Luke-Jr> also, age of coins is another factor
103 2013-11-20 08:33:05 <Luke-Jr> but in your case probably data size is the main one
104 2013-11-20 08:33:06 <tiyoT> Luke-Jr: thats what i mean, bigger data size.
105 2013-11-20 08:33:19 <tiyoT> age coins, old coin faster/slower?
106 2013-11-20 08:33:23 <Luke-Jr> tiyoT: if you spend 43 BTC often, you'll want to have people pay you volumes similar
107 2013-11-20 08:33:31 <Luke-Jr> old coin is higher priority
108 2013-11-20 08:33:37 <Luke-Jr> new coin is "probably spam"
109 2013-11-20 08:34:02 <tiyoT> how to initiate tx fee btw? sometimes when i use my bitcoinQT, they ask me if i want to pay for the fee (pop-up window) but most of the time they dont.
110 2013-11-20 08:34:38 <Luke-Jr> Settings menu, Optins
111 2013-11-20 08:36:30 <tiyoT> im using bitcoinQT for mac, i have to set my own tx fee
112 2013-11-20 08:36:52 <tiyoT> it says most transaction is 1 kB. and im asked to enter the amount. "Pay transaction fee"
113 2013-11-20 08:37:08 <tiyoT> how to determine the tx fee ?
114 2013-11-20 08:38:47 <tiyoT> Luke-Jr: Size
115 2013-11-20 08:39:03 <tiyoT> Luke-Jr: Estimated Confirmation Time
116 2013-11-20 08:39:26 <Luke-Jr> tiyoT: bc.i is full of crap
117 2013-11-20 08:39:52 <tiyoT> what should i use?
118 2013-11-20 08:41:05 <Luke-Jr> depends on how important fast confirmation is
119 2013-11-20 08:41:12 <Luke-Jr> try increments of 0.0001 BTC until you're happy
120 2013-11-20 08:53:01 <Ryan52> warren: whault mentions it happens only on his SSD. also possibly related to system sleep. that was a direction I was about to take in my considering of SSD issues, what if somehow there is a bug within them such that fsync has pushed changes they are now responsible for but do not properly handle when power issues change.
121 2013-11-20 08:54:09 <Ryan52> warren: I also considered sleep-related issues, because one user reported that it happened when "switching internet locations" while another reported not doing so. Perhaps this provides a clue as to it being related to sleep functionality, which also makes me wonder if I should have gotten a laptop for my testing :P.
122 2013-11-20 09:01:16 <gjs278> confirmation fees are retarded
123 2013-11-20 09:01:37 <gjs278> don't bother paying them, just let it happen slower
124 2013-11-20 09:07:53 <gavinandresen> tiyoT: 0.0005 is about the right fee-per-kilobyte number right now if you want your transaction to be confirmed quickly.
125 2013-11-20 09:21:28 <graingert> BlueMatt: good suggestions but a little too late.
126 2013-11-20 09:21:48 <graingert> It's on the site now. At least it doesn't say "Each (bitcoin has) a unique online registration number"
127 2013-11-20 09:22:00 <graingert> and these numbers are generated by mining puzles
128 2013-11-20 09:22:25 <graingert> BlueMatt: very good point about A/the Bitcoin client
129 2013-11-20 09:23:23 <warren> Ryan52: there  could have been multiple corruption causes.  things were patched 3 times for this.
130 2013-11-20 09:23:34 <warren> Ryan52: early reports were all over the place in behavior.
131 2013-11-20 09:23:47 <warren> Ryan52: you need to test with bitcoin 0.8.5 OMG3
132 2013-11-20 09:38:11 <Ryan52> warren: willdo, thanks.
133 2013-11-20 09:46:07 <warren> class CTxOut
134 2013-11-20 09:46:08 <warren> {
135 2013-11-20 09:46:08 <warren>     int64_t nValue;
136 2013-11-20 09:46:08 <warren> public:
137 2013-11-20 09:46:09 <warren>     CScript scriptPubKey;
138 2013-11-20 09:46:46 <warren> I'm in a method within a scriptPubkey.... there's no way to reach this nValue variable without explicitly passing it right?
139 2013-11-20 09:49:22 <Luke-Jr> of course
140 2013-11-20 10:01:57 <warren> I'm experimenting with dust expiration from the UTXO set.
141 2013-11-20 10:27:11 <warren> It turns out you can cause bitcoind to segfault if you do gettxoutsetinfo at the wrong moment.
142 2013-11-20 10:31:48 <wumpus> warren: backtrace?
143 2013-11-20 10:33:09 <warren> wumpus: i'll do it later with master first
144 2013-11-20 10:33:14 <warren> falling asleep
145 2013-11-20 12:58:24 <zveda> why is this transaction moving backwards in the queue? https://blockchain.info/tx/02984590d25f6eb79938119329e8dbb0596428c76f936ce99dbc17845491ab2d
146 2013-11-20 12:58:37 <tiyoT> gavinandresen: thanks for the suggestion, mind sharing the best way to calc the efficient tx fee?
147 2013-11-20 12:59:12 <lianj> zveda: backwards? its in a block now.
148 2013-11-20 12:59:40 <zveda> lianj: oh wow just as you said
149 2013-11-20 12:59:47 <zveda> it was waiting for several hours
150 2013-11-20 12:59:54 <TD> gavinandresen: are you there? do you remember in which release the relay fee was dropped?
151 2013-11-20 13:00:12 <TD> the release notes on bitcoin.org are unhelpful and i can't find a central repository of release notes. i'm sure there is one though
152 2013-11-20 13:07:29 <lianj> TD: 6de1326ba4a35ab781107a8b56f74affaed87cba
153 2013-11-20 13:07:40 <lianj> commit 6de1326ba4a35ab781107a8b56f74affaed87cba
154 2013-11-20 13:07:44 <lianj> Refs: v0.3.22-19-g6de1326
155 2013-11-20 13:08:01 <Apocalyptic> why was it dropped ?
156 2013-11-20 13:08:39 <TD> oh, wow, that's ancient. i thought the fee was dropped more recently
157 2013-11-20 13:08:57 <TD> hmm
158 2013-11-20 13:39:53 <bitnumus> two questions, is libboost 1.54 fine for bitcoind, and is BDB5.1 really an issue if the wallet is originally created using it ?
159 2013-11-20 13:40:08 <wumpus> bitnumus: yes, and no
160 2013-11-20 13:40:17 <bitnumus> thanks
161 2013-11-20 13:41:13 <sipa> BDB5.1 is fine if you don't intend to use the wallet on a BDB <5.1 build
162 2013-11-20 13:41:14 <wumpus> if your wallet was originally created using bdb5.1 you *have* to use bdb5.1 even, there is no backwards compatibility
163 2013-11-20 13:41:38 <wumpus> forwards*
164 2013-11-20 13:41:39 <bitnumus> ok, still trying to get bitcoind running on ARM
165 2013-11-20 13:41:45 <bitnumus> and i've found a debian build in unstable repo
166 2013-11-20 13:41:57 <bitnumus> its asking to install libboost 1.54 and BDB5.1 so i'm just going with it
167 2013-11-20 14:08:38 <phedny> when I do an importprivkey RPC call, I can set rescan to true or false; however, is it also possible to request a "rescan" for specific txids? in my use case, when I'm importing a private key, I know the txids of all relevant transactions, but the waiting time for a full rescan is too much
168 2013-11-20 14:18:28 <wumpus> phedny: no, there is no API for this
169 2013-11-20 14:29:18 <phedny> wumpus: okay.. and when doing a rescan as part of importprivkey, is only the newly imported key searched for or are all keys in the wallet rescanned?
170 2013-11-20 14:33:05 <wumpus> phedny: for all keys, that's why you can do it after importing a few of them
171 2013-11-20 14:33:47 <phedny> wumpus: okay, nice, that's not ideal, but can work for me in the short term :)
172 2013-11-20 14:33:50 <phedny> thank you!
173 2013-11-20 14:46:51 <clocKwize>  "bc62d4b80d9e36da29c16c5d4d9f11731f36052c72401a76c23c0fb5a9b7442381150608ffffffff96a15cb7f4cf73b725a25cb780f27db70000000069150608" any idae what I've messed up :)
174 2013-11-20 14:46:51 <clocKwize> hmm, I'm trying to port the sha2 code to another project, I've got it all building but the sha256d I get for "hello world" is "bc62d4b80d9e36da29c16c5d4d9f11731f36052c72401a76c23c0fb5a9b7442300f0a60601000000000000000e00000038081959ff7f00000000000000000000" but if I run that same test against the original source (pooler/cpuminer) I get
175 2013-11-20 14:48:33 <t7> not clearing the state?
176 2013-11-20 14:49:06 <clocKwize> What state?
177 2013-11-20 14:50:34 <clocKwize> I'm calling sha256d once from each code base, which I believe initializes the state itself as a local variable, so it should be clear each time right?
178 2013-11-20 14:56:47 <clocKwize> t7, does that make any sense? :)
179 2013-11-20 15:05:55 <wumpus> clocKwize: sha256 produces a 256 bit hash, which means 64 hex characters
180 2013-11-20 15:06:12 <wumpus> clocKwize: you're pasting 128, and the first 64 indeed seem to be the same...
181 2013-11-20 15:06:26 <clocKwize> true, its 64 bytes
182 2013-11-20 15:06:54 <clocKwize> which when formatted as 0 padded hex values, its 128 characters
183 2013-11-20 15:07:07 <Diablo-D3> clocKwize: yeah but you actually need those 0s.
184 2013-11-20 15:07:33 <clocKwize> https://gist.github.com/brightbits/3c0e112d216e94e97233
185 2013-11-20 15:07:33 <clocKwize> I'm doing this
186 2013-11-20 15:09:57 <clocKwize> is that not correct?
187 2013-11-20 15:23:45 <clocKwize> Diablo-D3, wumpus?
188 2013-11-20 15:24:49 <Diablo-D3> clocKwize: wasnt that a radio station or something?
189 2013-11-20 15:25:01 <clocKwize> huh?
190 2013-11-20 15:25:35 <Diablo-D3> the name sounds familiar I cant remember why
191 2013-11-20 15:25:55 <clocKwize> My name? Just made it up
192 2013-11-20 15:25:59 <bitnumus> hey, how long should this take >  Rescanning last 270615 blocks (from block 0)...
193 2013-11-20 15:26:07 <Diablo-D3> clocKwize: no, wumpus
194 2013-11-20 15:26:10 <clocKwize> oh
195 2013-11-20 15:26:13 <clocKwize> :p
196 2013-11-20 15:36:58 <clocKwize> Diablo-D3: the last 32 bytes change on both code bases, is that normal O.o
197 2013-11-20 15:37:19 <EasyCompany2020> Hey
198 2013-11-20 15:37:38 <clocKwize> I'm confused, sha256 is 64 bytes, in the real implementation its returning 32 static bytes, then 32 bytes that differ each run, leaving me confused.
199 2013-11-20 15:38:10 <EasyCompany2020> Does anyone know how to use makefile on windows?
200 2013-11-20 15:38:39 <wumpus> download msys
201 2013-11-20 15:39:49 <wumpus> (or cygwin, but that's a full unix OS on top of windows, probably overkill)
202 2013-11-20 15:39:57 <sipa> clocKwize: sha256 reads 64 bytes in each block, but has 32 byte output
203 2013-11-20 15:40:12 <clocKwize> sipa that would explain
204 2013-11-20 15:40:29 <wumpus> that's what I said too, but he wouldn't believe it :p
205 2013-11-20 15:40:42 <clocKwize> wumpus: I didn't disbelieve you, I'm just confused
206 2013-11-20 15:40:52 <clocKwize> and you didn't elaborate to any of my questions :)_
207 2013-11-20 15:41:35 <clocKwize> this code: https://gist.github.com/brightbits/b092daac3b766ff92e3e#file-gistfile1-txt-L3 is where I took a sample call to sha256d from, that uses a 64 byte buffer :s
208 2013-11-20 15:45:05 <sipa> clocKwize: well look up the documentation for that function
209 2013-11-20 15:45:14 <sipa> there may be more internal state that is kept
210 2013-11-20 15:45:32 <sipa> which may be implementation dependent
211 2013-11-20 15:47:54 <clocKwize> ah, just actually looked at what a merkle root is ;p
212 2013-11-20 16:13:59 <Diablo-D3> [10:37:29] <clocKwize> I'm confused, sha256 is 64 bytes, in the real implementation its returning 32 static bytes, then 32 bytes that differ each run, leaving me confused.
213 2013-11-20 16:14:05 <Diablo-D3> you mean with mining?
214 2013-11-20 16:14:08 <Diablo-D3> thats actually normal
215 2013-11-20 16:14:24 <Diablo-D3> mining exploits the part of the data that doesnt change, too
216 2013-11-20 16:14:50 <Diablo-D3> if you're outside of mining, thats not normal
217 2013-11-20 16:14:58 <Diablo-D3> because every bit of input changes every bit of output
218 2013-11-20 16:15:05 <Diablo-D3> (well, can change)
219 2013-11-20 16:18:25 <clocKwize> Diablo-D3: yes, worked it out now, it was as expected, i should have only been looking at the first 32 bytes, I was confused
220 2013-11-20 16:19:17 <Diablo-D3> I love how mining takes more than one pass to mine
221 2013-11-20 16:19:27 <Diablo-D3> 80 bytes input, 64 bytes at a time
222 2013-11-20 16:19:35 <Diablo-D3> makes mining so fast
223 2013-11-20 16:19:46 <clocKwize> I don't really understand it (yet)
224 2013-11-20 16:19:53 <clocKwize> also, I thought mining was meant to be slow ;p
225 2013-11-20 16:20:32 <clocKwize> I'm basically reengineering cpuminer
226 2013-11-20 16:20:34 <clocKwize> to learn
227 2013-11-20 16:22:12 <clocKwize> should have done this 3 years ago when bitcoins were worthless, now I'd be rich ;p
228 2013-11-20 16:26:40 <Diablo-D3> clocKwize: heh
229 2013-11-20 16:30:22 <EasyCompany2020> Hey when trying to make the make file in i get Makefile.am:86 *** Mission seperator. Stop.
230 2013-11-20 16:31:03 <clocKwize> 
231 2013-11-20 16:31:29 <clocKwize> http://www.chaucercollege.co.uk/
232 2013-11-20 16:57:19 <Matoking> I have a quick question regarding sendmany Bitcoin JSON-RPC function
233 2013-11-20 16:57:58 <Matoking> Presumably the first parameter sets which addresses the bitcoins are sent from
234 2013-11-20 16:58:14 <sipa> you cannot send from an address
235 2013-11-20 16:58:29 <Matoking> Well, account
236 2013-11-20 16:58:47 <sipa> it sets which account to debit for the spend, yes
237 2013-11-20 16:59:31 <Matoking> I would like it to work like sendtoaddress so that it doesn't need an account to be specified
238 2013-11-20 16:59:41 <Matoking> Or does '' or something else work as a wildcard?
239 2013-11-20 16:59:52 <sipa> if you're not using accounts, you always use the '' account
240 2013-11-20 17:00:00 <sipa> so you can specify '' just fine
241 2013-11-20 17:00:11 <sipa> it's not special, it's just a default
242 2013-11-20 17:00:29 <Matoking> Okay, let's say I have a Bitcoin wallet with addresses, some which have labels so that they are labeled as accounts of the same name
243 2013-11-20 17:01:02 <Matoking> Is there a way that I can ensure the bitcoins are sent, even though the specified account doesn't have enough bitcoins but the Bitcoin wallet as whole has enough bitcoins?
244 2013-11-20 17:01:17 <Matoking> Or do I have to just reset every account name to ''?
245 2013-11-20 17:01:39 <sipa> oh, right, sendmany fails in case there are not enough funds in the account?
246 2013-11-20 17:01:53 <sipa> you can use move to set the value of '' to anything
247 2013-11-20 17:02:04 <Matoking> Yep
248 2013-11-20 17:02:45 <Matoking> In retrospect I should have just forgot about using labels and accounts with wallets for web services
249 2013-11-20 17:03:16 <Matoking> Thanks for the help
250 2013-11-20 17:20:15 <TD> sipa: are you attempting to do full-match merkle blocks?/
251 2013-11-20 17:20:35 <sipa> TD: yes
252 2013-11-20 17:20:49 <TD> excellent :)
253 2013-11-20 17:21:08 <TD> i guess that is the next most important step for increasing block capacity and dropping confirm times
254 2013-11-20 17:28:17 <t7> i wonder if in the future we will have a quantum signing process such that signing something away generates a new private key and if the signer peeks at the private key it would invalidate it....
255 2013-11-20 17:28:37 <t7> (well just change it)
256 2013-11-20 17:29:30 <t7> my quantum fairy tails
257 2013-11-20 17:29:57 <t7> tales(?)
258 2013-11-20 17:33:45 <gmaxwell> t7: see the quantum digital cash papers, they basically amount to representing money as qbits with a transfer of value process that teleports the quantum state without observing it.  It's kinda silly and non-pratical but fun to think about.
259 2013-11-20 17:39:07 <groglogic> i've personally experienced cash teleporting out of my wallet before, but it typically only happened while inside the LEGO store in downtown Chicago
260 2013-11-20 18:01:48 <skinnkavaj> gmaxwell
261 2013-11-20 18:02:08 <skinnkavaj> Regarding taking very long time for transactions to get confirmations now
262 2013-11-20 18:02:12 <skinnkavaj> Is this true?
263 2013-11-20 18:02:24 <skinnkavaj> "If only there was a way the originator of a transaction could directly connect to multiple mining pools of his own choosing and send his transaction to all of them simultaneously. Oh wait, there is a way: the way I just said. "
264 2013-11-20 18:09:10 <gmaxwell> skinnkavaj: what the hell are you talking about?
265 2013-11-20 18:12:26 <kjj> I don't want to put words in his mouth, but I suspect he is confused regarding the distinction between a miner knowing about a transaction and a miner including it in a block
266 2013-11-20 18:12:38 <skinnkavaj> Yeah thats it
267 2013-11-20 18:14:21 <groglogic> skinnkavaj: my semi-informed edu-guess is that the recent spike over the last week and esp days has caused new txn rate to increase out of proportion to avail mining power. thus, the slowdown. if that's the case two no-think/no-code-change solutions are there need to be more miners and folks need to offer higher fees to see their txns get varified faster
268 2013-11-20 18:14:54 <gmaxwell> groglogic: yea, thats completely uninformed.
269 2013-11-20 18:14:59 <gmaxwell> Thanks for trying to help though.
270 2013-11-20 18:15:09 <groglogic> gmaxwell: ok good. that's what i was hoping :-P
271 2013-11-20 18:15:45 <groglogic> gmaxwell: i hate doing anything semi-assed. prefer fully informed or completely wildly off the market ;-)
272 2013-11-20 18:16:04 <groglogic> gmaxwell: er, off the mark. wildly
273 2013-11-20 18:16:20 <groglogic> on a serious note
274 2013-11-20 18:16:21 <gmaxwell> Can we please not have the nebie question stuff in this channel? You'll actually get better answers in #bitcoin where there are more active people around who will hapily answer questions on this stuff.
275 2013-11-20 18:16:36 <groglogic> agreed
276 2013-11-20 18:17:11 <kjj> hmm...  thinking out loud...  automatically generate 3 or 4 extra change addresses...  API to let your client turn one of them into a bribe to an address provided by the miner's API...
277 2013-11-20 18:18:16 <gmaxwell> kjj: or you could ... just pay fees. Which happily "bribes" all miners, not just one.
278 2013-11-20 18:18:44 <kjj> I'm thinking about a situation where there is a spike in transaction rate and your calculated fees might not be enough
279 2013-11-20 18:20:03 <gmaxwell> kjj: if more miners were doing child-pays then you could just count on spending the unconfirmed coins with more fees. Well, I guess about 15-20% of the hashpower is now.
280 2013-11-20 18:21:32 <kjj> I always end up thinking that it would be really nifty if transactions in the mempool could be flagged in various ways
281 2013-11-20 18:22:04 <gmaxwell> like https://github.com/bitcoin/bitcoin/pull/1583 ?
282 2013-11-20 18:22:36 <kjj> more
283 2013-11-20 18:23:17 <kjj> "include in mined blocks, but don't transmit", "discard if conflict is received", etc
284 2013-11-20 18:24:37 <groglogic> kjj: those are test scenario ideas? (i got disco'ed by my wifi a bit, may have missed something)
285 2013-11-20 18:27:01 <kjj> groglogic: I'm thinking flags for transactions
286 2013-11-20 18:28:28 <kjj> think of a p2pool user with hundreds of small rewards that need to be cleaned up.  he could make a HUGE consolidation transaction, and flag it for no-broadcast so that it ends up in HIS next block
287 2013-11-20 18:44:34 <BlueMatt> hmm...a node just got disconnected from a relay node for relaying a tx with 0inputs/outputs
288 2013-11-20 18:44:55 <jouke> welcome to the club
289 2013-11-20 18:45:06 <kjj> quantity zero, or value zero?
290 2013-11-20 18:45:20 <BlueMatt> this one needs solved...
291 2013-11-20 18:45:22 <BlueMatt> quanitity
292 2013-11-20 18:46:05 <kjj> sounds right to me.  quantity zero inputs isn't a valid transaction.  I'd disconnect too
293 2013-11-20 18:46:21 <BlueMatt> perfectly reasonable bitcoind's are relaying them, is my point
294 2013-11-20 18:46:28 <kjj> or are you on the node side, wondering why it did that?
295 2013-11-20 18:46:41 <BlueMatt> its something thats been seen on many nodes for a while
296 2013-11-20 18:46:41 <kjj> hmm.  do you have the peer info?
297 2013-11-20 18:49:44 <gmaxwell> We've had people here reporting it on their own nodes.
298 2013-11-20 19:07:22 <lianj> wasn't me. promise
299 2013-11-20 20:30:27 <flatfly> does anyone know of a good script (python/ruby/etc) to recover a wallet.dat password from a pywallet dump?
300 2013-11-20 20:30:38 <flatfly> and only have access to a partial dump (not the full wallet.dat)
301 2013-11-20 20:30:38 <flatfly> i'm trying to help someone who remembers most of his password,
302 2013-11-20 20:40:03 <Ry4an> if they don't have the full wallet.dat what good will finding the password do them?
303 2013-11-20 20:46:00 <flatfly> they do have the full wallet.dat, but i don't
304 2013-11-20 20:46:20 <flatfly> i'm working with a partial export they sent me
305 2013-11-20 20:46:55 <flatfly> it's a no-trust way of helping someone recover access to their wallet
306 2013-11-20 20:47:49 <Ry4an> ah, clever
307 2013-11-20 20:52:49 <jaakkos> is there a recent graph for number of bitcoin nodes connected?
308 2013-11-20 20:57:10 <phantomcircuit> jaakkos, it's ~4500 available
309 2013-11-20 20:57:17 <phantomcircuit> public nodes end up with ~35 connections
310 2013-11-20 20:57:29 <phantomcircuit> so ;;calc 4500*(35/8)
311 2013-11-20 20:57:35 <gribble> 19687.5
312 2013-11-20 20:57:35 <phantomcircuit> ;;calc 4500*(35/8)
313 2013-11-20 20:57:39 <phantomcircuit> 20k nodes
314 2013-11-20 20:57:40 <phantomcircuit> roughly
315 2013-11-20 20:57:46 <phantomcircuit> or is that 24500
316 2013-11-20 20:57:49 <phantomcircuit> shrug
317 2013-11-20 20:58:52 <jaakkos> ok
318 2013-11-20 22:26:14 <gmaxwell> I'm obviously failing to communicate with the guy here: https://github.com/bitcoin/bitcoin/issues/3288
319 2013-11-20 22:26:18 <gmaxwell> can someone else give it a shot?
320 2013-11-20 22:29:00 <Apocalyptic> gmaxwell, not worth it
321 2013-11-20 22:30:35 <edcba> is there a project to handle many wallets with the official client ?
322 2013-11-20 22:32:18 <Luke-Jr> edcba: CodeShark used to be working on that, not sure if he's given up on it though
323 2013-11-20 22:33:07 <TD> if a node sends an already confirmed tx to a peer in a tx message, it's considered to be an orphan, right? because the inputs aren't in the utxo set
324 2013-11-20 22:33:19 <TD> or is it seen as a double spend
325 2013-11-20 22:34:03 <jgarzik> td: it's dropped as invalid
326 2013-11-20 22:36:49 <TD> how can it reliably tell the difference with no tx index?
327 2013-11-20 22:38:35 <edcba> TD: is it necessary ?
328 2013-11-20 22:39:30 <TD> probably not. i was just wondering in case "double spending" is treated differently in future to repetitive broadcasts
329 2013-11-20 22:40:35 <edcba> only field that could tell difference seems to be lock_time from what i see
330 2013-11-20 22:40:53 <edcba> and that's a "could"
331 2013-11-20 22:45:02 <jaakkos> let's say someone put up a bitcoin exchange or a web wallet. can you think of a way the people running the site could prove the coins were stolen in case the service got hacked?
332 2013-11-20 22:45:24 <jaakkos> as in, stolen by someone else but the site's admins.
333 2013-11-20 22:46:08 <jaakkos> that sounds quite impossible. can you suggest some other approach?
334 2013-11-20 22:47:08 <petertodd> jaakkos: the only way I've ever found is to carefully make stealing the coins unprofitable with fidelity bonds, alone or with secure hardware with well defined minimum costs to hack
335 2013-11-20 22:47:13 <matjeh> encrypt/decrypt and create transactions client-side, in javascript, and only ever store/transmit the encrypted wallets, and the created transactions
336 2013-11-20 22:47:35 <petertodd> jaakkos: not directly what you want, but what that accomplishes is what you actually want
337 2013-11-20 22:47:49 <petertodd> jaakkos: basically what society already does of course...
338 2013-11-20 22:49:24 <jaakkos> matjeh: i was thinking of that. however, i can't think of a way to avoid polluting the block chain
339 2013-11-20 22:49:59 <jaakkos> matjeh: in case it's an exchange.
340 2013-11-20 22:50:17 <petertodd> jaakkos: s/polluting/using/...
341 2013-11-20 22:50:37 <petertodd> jaakkos: no need to put values into this discussion :P
342 2013-11-20 22:51:16 <jaakkos> good point :)
343 2013-11-20 22:52:01 <jaakkos> i need to look into fidelity bonds...
344 2013-11-20 22:52:38 <jaakkos> do you know what is the approach taken by big services such as gox, stamp, btcchina, bitpay, etc?
345 2013-11-20 22:52:55 <jaakkos> (and if you do, are you willing to tell :))
346 2013-11-20 22:52:57 <petertodd> jaakkos: yeah, though be warned there's a tremendous amount of subtlety required to use them effectively
347 2013-11-20 22:53:27 <petertodd> jaakkos: some are allegedly using HSM's, but not with remote-attestation so it's irrelevant to their customers. Basically you can sum it up as "Trust us."
348 2013-11-20 22:53:36 <petertodd> jaakkos: Easy to improve upon that. :)
349 2013-11-20 23:16:14 <sipa> i see 5.3k well-reachable nodes!
350 2013-11-20 23:16:47 <bwen> would it be complicated to get notified of new blocks and list of transactions in it without running a node or client bitcoin nor using a third partie API ?
351 2013-11-20 23:17:10 <sipa> bwen: then by what would you be notified...?
352 2013-11-20 23:17:46 <bwen> I dummy click that only get block notification then parse it and insert it in a db...
353 2013-11-20 23:17:54 <bwen> thin thin thin client
354 2013-11-20 23:18:02 <sipa> yes, so a very simple node
355 2013-11-20 23:18:05 <bwen> dummy client*
356 2013-11-20 23:18:06 <bwen> :P
357 2013-11-20 23:18:08 <sipa> there are python tools that do that
358 2013-11-20 23:18:16 <sipa> pynode maybe
359 2013-11-20 23:18:29 <bwen> yeah i've looked a bit, but i'm not looking for a full node
360 2013-11-20 23:18:39 <bwen> nor a wallet that can process transaction
361 2013-11-20 23:18:40 <sipa> nor am i talking about a full node
362 2013-11-20 23:19:14 <bwen> i'd like to under take this thin client on my own as a learning experience
363 2013-11-20 23:19:29 <bwen> hence why I am not really looking for a third party tool
364 2013-11-20 23:19:47 <sipa> you want to write it yourself?
365 2013-11-20 23:19:54 <bwen> sure  :)
366 2013-11-20 23:20:09 <sipa> no, i mean, what is your goal?
367 2013-11-20 23:21:00 <bwen> a Client daemon that gets notified by the bitcoin network when new blocks are found and logs the block in a database
368 2013-11-20 23:21:15 <bwen> does not parse the WHOLE blockchain. just new blocks
369 2013-11-20 23:21:53 <bwen> I guess what i'm asking is really the part: How can I make a client that gets notified by the bitcoin network of new blocks
370 2013-11-20 23:22:21 <sipa> bwen: https://github.com/jgarzik/pynode/tree/mini-node
371 2013-11-20 23:23:03 <bwen> sweet i'll be dissecting that, thx :D
372 2013-11-20 23:30:57 <bwen> hmm how do I handshake a connection with the bitcoin network... How do I find the first IP (for TestNet or Bitcoin) ?
373 2013-11-20 23:31:16 <sipa> you connect to a trusted node
374 2013-11-20 23:31:34 <sipa> unless you do verification of the data yourself, you shouldn't trust what a random other node tells you
375 2013-11-20 23:31:44 <bwen> I remember hearing that in the early days it used to connect to irc channel to get a list :P
376 2013-11-20 23:31:54 <sipa> there are DNS seeds now
377 2013-11-20 23:32:08 <melvster> anyone know ... how many systems support lock_time, right now?
378 2013-11-20 23:32:08 <sipa> but don't use them unless you actually have a (fully or simplified) verifying node
379 2013-11-20 23:33:23 <bwen> right, where can I read more about the DNS seeds? thats all trusted nodes ? if not how do I find a trusted node?
380 2013-11-20 23:33:38 <sipa> a trusted node == a node you trust
381 2013-11-20 23:33:53 <sipa> you shouldn't trust someone else's stuff unless you know them or pay them for it :p
382 2013-11-20 23:34:02 <sipa> dns seeds are only to find random other nodes
383 2013-11-20 23:34:10 <bwen> aight
384 2013-11-20 23:34:11 <sipa> whether they're trusted is something you need to decide
385 2013-11-20 23:34:45 <bwen> I guess the DNS seeds is a good start :)
386 2013-11-20 23:34:56 <sipa> NOOO
387 2013-11-20 23:35:13 <sipa> don't connect a non-verifying node to random peers
388 2013-11-20 23:36:02 <bwen> well for dev purpose its good enough, I'll hardcode a trusted node. Or a list of trusted nodes
389 2013-11-20 23:36:26 <bwen> but I havent decided yet who'll be the trust nodes... hence the: good enough for now
390 2013-11-20 23:36:40 <sipa> sure, for dev purposes just connect to some random node
391 2013-11-20 23:37:37 <warren> sipa: is there a graph of good listening nodes/time?
392 2013-11-20 23:37:44 <sipa> no
393 2013-11-20 23:40:28 <gavinandresen> melvster: what do you mean "support lock_time" ?  Time-locked transactions are fully supported, but they won't get relayed across the network until after the time lock expires (which just means you need one or both of the parties to the transaction to hold it until then)
394 2013-11-20 23:41:15 <gavinandresen> (or I suppose somebody could start a service to hold time-locked transactions for people, maybe in exchange for a small fee…)
395 2013-11-20 23:41:43 <melvster> gavinandresen: thanks for the explanation ... that answers my question
396 2013-11-20 23:42:20 <bwen> a small... bitcoin fee... which... we'll hardcode... just to be sure it doesnt scale... I'm IN! :D *wink wink*
397 2013-11-20 23:42:21 <gmaxwell> melvster: what was your question? Gavin gave a "answer all possible questions" answer, but I'm curious as to what you were actually asking about. What did you mean by support?
398 2013-11-20 23:43:27 <melvster> gmaxwell: i was wondering to what extent lock_time had been implemented ... i was reading about lock_time and nlocktime and they seem like fascinating concepts, i wanted to try and work out what stage it was at
399 2013-11-20 23:43:49 <melvster> e.g. in the reference implementation
400 2013-11-20 23:44:18 <sipa> locktime is fully implemented
401 2013-11-20 23:44:34 <gmaxwell> melvster: it's not the sort of thing which is very agreeable to a gradual implementation, as enforcing it is a blockchain validation rule.
402 2013-11-20 23:45:01 <melvster> got it, makes sense
403 2013-11-20 23:45:07 <gavinandresen> people often miss that locktime is ignored if all the input sequence numbers are MAX_INT, and think it isn't supported because it doesn't work for them
404 2013-11-20 23:46:19 <amincd> is there somewhere I can read more about pruning, and the development timeline on it?
405 2013-11-20 23:46:44 <sipa> implementing is very easy
406 2013-11-20 23:47:06 <sipa> it's making sure that nodes will still find non-pruned nodes to fetch blocks from afterwards that's slightly harder
407 2013-11-20 23:48:06 <amincd> will there be pruned and non-pruned versions?
408 2013-11-20 23:48:19 <amincd> I'm concerned about the size of the blockchain when, inevitably, the blocksize limit is raised
409 2013-11-20 23:48:41 <sipa> basically you can keep blocks or not
410 2013-11-20 23:48:48 <sipa> or just the most recent ones
411 2013-11-20 23:49:09 <sipa> the problem is that nodes that have missed some blocks, or are just syncing from scratch, still need to find them
412 2013-11-20 23:49:22 <sipa> so pruning is not about having less to download, you still need to see every block
413 2013-11-20 23:49:27 <sipa> you just don't need to keep all of them
414 2013-11-20 23:49:42 <amincd> so nodes will have to advertise whether they're full blockchain carriers or pruned nodes
415 2013-11-20 23:49:57 <sipa> indeed
416 2013-11-20 23:50:03 <warren> amincd: it's been proposed that future nodes might be called 'archive nodes'
417 2013-11-20 23:50:08 <sipa> and we need to agree on a way to advertize that
418 2013-11-20 23:51:36 <amincd> thanks
419 2013-11-20 23:54:16 <radiator> hi. how long should a tx with 0.0001 btc fee take to confirm ?