1 2013-12-21 00:00:26 <coingenuity> ah, alright
  2 2013-12-21 00:00:41 <coingenuity> well disk is already mega fast so it should just be smooth as butter at 2k
  3 2013-12-21 00:00:57 <coingenuity> doubt the ram buffer of data to write will ever exceed that
  4 2013-12-21 00:00:57 <sipa> dbcache helps both preventing writes and reads
  5 2013-12-21 00:03:42 <coingenuity> okie dokie, thanks sipa - will give it a shot and see how fast it goes
  6 2013-12-21 01:52:59 <HaltingState> gmaxwell, how do i stop gribble from spamming me every login
  7 2013-12-21 01:54:39 <mtbomb> HaltingState: Are you using freenode?
  8 2013-12-21 01:54:49 <HaltingState> yes
  9 2013-12-21 01:55:01 <mtbomb> theres an IRC icon in the upper left
 10 2013-12-21 01:55:10 <HaltingState> i am on xchat
 11 2013-12-21 01:55:23 <HaltingState> everytime i login gribble messages me to remind me not to be noob
 12 2013-12-21 01:55:23 <mtbomb> oh, I don't know that program
 13 2013-12-21 01:55:39 <TheLordOfTime> HaltingState, you can't stop that
 14 2013-12-21 01:55:41 <TheLordOfTime> not possible
 15 2013-12-21 01:55:47 <TheLordOfTime> the entrymsg always happens every time you reconnect
 16 2013-12-21 01:55:59 <TheLordOfTime> short of ignoring ALL gribble messages you're going to just have to stop closing IRC
 17 2013-12-21 01:56:03 <TheLordOfTime> either that or get an IRC bouncer
 18 2013-12-21 01:58:44 <HaltingState> ;;disable
 19 2013-12-21 01:58:45 <gribble> Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
 20 2013-12-21 01:59:10 <HaltingState> there are a billion commands but no command to turn off greeting lol
 21 2013-12-21 01:59:29 <TheLordOfTime> HaltingState, you obviously missed my messages
 22 2013-12-21 01:59:30 <TheLordOfTime> [2013/12/20 20:55:37] <TheLordOfTime> HaltingState, you can't stop that
 23 2013-12-21 01:59:30 <TheLordOfTime> [2013/12/20 20:55:39] <TheLordOfTime> not possible
 24 2013-12-21 01:59:37 <TheLordOfTime> HaltingState, there's no option in the bot to "disable" that yourself
 25 2013-12-21 01:59:52 <HaltingState> if ;;disable worked, it would have fixed the problem =P
 26 2013-12-21 01:59:54 <TheLordOfTime> so short of setting an ignore globally on gribble in your irc client the only other option is to not turn off IRC
 27 2013-12-21 02:00:00 <HaltingState> i will get bouncer
 28 2013-12-21 02:00:12 <maaku> Compile error Mac OS X 10.9
 29 2013-12-21 02:00:13 <maaku> Undefined symbols for architecture x86_64: "Db::verify(char const*, char const*, std::basic_ostream<char, std::char_traits<char> >*, unsigned int)", referenced from:
 30 2013-12-21 02:00:17 <maaku> anyone encountered this?
 31 2013-12-21 02:15:36 <shesek> I really think someone should publish xchat/irssu/mirc plugins to ignore gribble's warnings, I see people (including myself) asking about that like 5 times a day
 32 2013-12-21 02:16:33 <ne0futur> better than people getting scammed 5 times a day . . .
 33 2013-12-21 02:18:21 <shesek> I'm pretty sure that those who've seen it enough times to want to opt-out won't be scammed because they stop getting those messages
 34 2013-12-21 02:19:11 <sipa> what message?
 35 2013-12-21 02:19:26 <maaku> i don't see any message either...
 36 2013-12-21 02:19:28 <shesek> gribble's warnings about malwares
 37 2013-12-21 02:19:44 <sipa> which channel?
 38 2013-12-21 02:20:08 <shesek> I think its sent to everyone who joins #bitcoin / #bitcoin-otc
 39 2013-12-21 02:20:23 <shesek> I have so many bitcoin-related channels open that I'm not really sure, heh
 40 2013-12-21 02:20:36 <sipa> oh
 41 2013-12-21 02:20:48 <sipa> meh
 42 2013-12-21 02:21:19 <sipa> a good reason not to join/quit all the time :)
 43 2013-12-21 02:21:51 <shesek> you can't really help it when you have a crappy internet provider :(
 44 2013-12-21 02:22:19 <sipa> run your irc client remotely :)
 45 2013-12-21 02:22:20 <upb> shell+screen/tmux+irssi
 46 2013-12-21 02:23:05 <sipa> yeah, that - though it's not really a solution for everyone
 47 2013-12-21 02:24:12 <shesek> I tried, but I really can't stand non-gui irc clients (and I'm using vim as my primary editor)
 48 2013-12-21 02:29:53 <lianj> shesek: http://wiki.znc.in/ZNC irc bouncer
 49 2013-12-21 02:31:11 <shesek> yeah, I guess I could set up a bouncer...
 50 2013-12-21 02:31:31 <shesek> or I can just live with gribble's messages, which is much easier :-)
 51 2013-12-21 02:32:14 <maaku> shesek: quassel
 52 2013-12-21 02:32:42 <maaku> http://quassel-irc.org/
 53 2013-12-21 02:32:58 <lianj> shesek: saying connected is a bit more convenient though
 54 2013-12-21 02:33:03 <lianj> but whatever :)
 55 2013-12-21 02:33:54 <shesek> yes, it definitely has some other advantages, but too much hassle imho
 56 2013-12-21 02:34:09 <shesek> especially nowadays with memoserv
 57 2013-12-21 02:34:48 <shesek> was much useful a few years back when none of that fancy services existed :)
 58 2013-12-21 02:36:16 <shesek> well, memoserv and chanserv/nickserv... back in the day, if you disconnected someone else might've taken over your channel
 59 2013-12-21 02:36:54 <shesek> maaku, quassel looks pretty neat, but I think I'm too used for xchat now
 60 2013-12-21 06:30:13 <warren> sipa: according to the acoustic cryptanalysis paper apparently gmp's optimizations making it non-constant time substantially enabled that attack.  would that be a similar concern for secp256k1 + gmp?
 61 2013-12-21 06:33:07 <gmaxwell> warren: the openssl signing is already substantially not constant time. There is no pretext of timing/power-analysis security in any bitcoin signing code I've seen in existance.
 62 2013-12-21 06:34:00 <CodeShark> in practice, timing/power-analysis attacks on openssl in this context are difficult
 63 2013-12-21 06:34:05 <gmaxwell> But none of the implementations I'm aware of allow an attacker to on-demand trigger on demand signing with fully attacker chosen inputs (the non-determinism of DSA makes that impossible)
 64 2013-12-21 06:34:26 <gmaxwell> warren: that audio thing requires automatic decryption of thousands of messages, it's neat but not exactly a pratical attack.
 65 2013-12-21 06:35:20 <CodeShark> I have a constant-time implementation of signing, but it's significantly slower than openssl
 66 2013-12-21 06:35:36 <CodeShark> in particular, the modular inverse
 67 2013-12-21 06:35:45 <gmaxwell> as expected.
 68 2013-12-21 06:35:49 <gmaxwell> And thats fine.
 69 2013-12-21 06:36:06 <warren> ok thanks
 70 2013-12-21 06:36:08 <gmaxwell> CodeShark: Sipa did want to add constant time signing stuff for his library.
 71 2013-12-21 06:36:46 <CodeShark> gmaxwell: yes, I contributed a few commits for that
 72 2013-12-21 06:36:52 <gmaxwell> CodeShark: you still probably have a power analysis vulnerability, but its probably prudent to use a constant time one regardless.
 73 2013-12-21 06:36:53 <CodeShark> but we never finished it completely
 74 2013-12-21 06:37:23 <CodeShark> the modular inverse can be implemented as a constant-time modular exponentiation
 75 2013-12-21 06:38:09 <CodeShark> which is significantly slower than lehman's algorithm, but far simpler to make constant-time
 76 2013-12-21 06:38:51 <CodeShark> sipa and I had also discussed how to make curve operations constant-time
 77 2013-12-21 06:40:25 <CodeShark> in any case, the secp256k1 library only needs to worry about optimizing verification, not signing
 78 2013-12-21 06:40:36 <CodeShark> and verification does not need to be constant time
 79 2013-12-21 06:41:09 <CodeShark> so perhaps verification and signing use different implementations of the math library
 80 2013-12-21 06:42:22 <CodeShark> power analysis can also be defeated by ensuring that the CPU performs the exact same instructions without branching regardless of input
 81 2013-12-21 06:44:12 <warren> https://blog.goeswhere.com/2010/12/git-set-commit-id/  let's use this in some bad way.
 82 2013-12-21 07:11:52 <sharperguy> Does bitcoin have an option to create a transaction which will be automatically reversed if the outputs are not spent in a certain amount of time?
 83 2013-12-21 07:17:13 <CodeShark> not that I'm aware of...
 84 2013-12-21 07:26:39 <Luke-Jr> well, you could pre-arrange a nlocktime transaction sending it back to a single person
 85 2013-12-21 08:27:37 <MadrMan> is this where I can ask miner dev stuff? or is there a better chan?
 86 2013-12-21 08:29:06 <sipa> 1#bitcoin-mining perhaps
 87 2013-12-21 08:30:19 <MadrMan> that's not related to dev, is it?
 88 2013-12-21 08:33:39 <MadrMan> anyway, i was wondering how to calculate the merkle root from a getblocktemplate call, as it doesn't seem to return a 'coinbasetxn', and has an empty transactions list..
 89 2013-12-21 08:37:40 <CodeShark> it does return a transactions list - at least the version I'm looking at
 90 2013-12-21 08:38:01 <MadrMan> using it on an altcoin, guess less transactions are happening there
 91 2013-12-21 08:38:08 <MadrMan> "transactions" : [],
 92 2013-12-21 08:38:19 <CodeShark> yeah, then perhaps the mempool is empty
 93 2013-12-21 08:38:35 <BlueMatt> heh, most altcoins have absolutely 0 transaction volume
 94 2013-12-21 08:38:41 <BlueMatt> they are 100% speculation
 95 2013-12-21 08:39:23 <CodeShark> as for coinbase, it's up to you to add an output
 96 2013-12-21 08:39:41 <sipa> MadrMan: irrelevant, unless the altcoin changed the way blick hashes are computed
 97 2013-12-21 08:39:48 <sipa> you create tge coinbase
 98 2013-12-21 08:40:01 <sipa> add the rest of the transactions
 99 2013-12-21 08:40:09 <sipa> and compute the merkle tree
100 2013-12-21 08:40:42 <MadrMan> ah that makes sense, thanks
101 2013-12-21 08:40:59 <MadrMan> wiki made it seem like the coinbasetxn was always supplied
102 2013-12-21 08:42:44 <CodeShark> how would it know where to send the coins?
103 2013-12-21 08:45:32 <sipa> it may
104 2013-12-21 08:45:45 <sipa> for example if you're mining in a pool
105 2013-12-21 08:46:16 <CodeShark> how would the getblocktemplate call know where to send the coins?
106 2013-12-21 08:47:08 <BlueMatt> wow, looks like no part of the bloom filter stuff was in any way thought through. turns out not only was the implementation bugged, but the design doesnt really allow for reasonable false positive anonymity-performance tradeoffs :(
107 2013-12-21 08:47:40 <BlueMatt> the anonymity set is <fp_rate**2 (over set of pubkeys in chain), but fp rate on txn is, on avg, something like 5*fp_rate
108 2013-12-21 08:48:17 <sipa> CodeShark: getblocktemplate is a protocol; bitcoind is just one implementation
109 2013-12-21 08:48:38 <CodeShark> so the coinbase transaction outputs could be supplied via parameter?
110 2013-12-21 08:49:23 <sipa> if you call gbt to a pool, it will give you the coinbase tx
111 2013-12-21 08:57:29 <uiop> BlueMatt: (out of curiosity) what does the bloom filter have to do with anonymity?
112 2013-12-21 09:31:27 <wumpus> uiop: by setting a bloom filter you're revealing the set of keys you're interested in, this which are in your wallet
113 2013-12-21 09:31:34 <wumpus> s/this/thus/
114 2013-12-21 09:36:44 <uiop> wumpus: oh. i hadn't looked at the bip37 except for the title, and assumed the bloom filter was being used as an optim to avoid disk reads (or something)
115 2013-12-21 09:36:58 <uiop> 
ACTION has just looked at the content of bip37

116 2013-12-21 09:38:16 <wumpus> uiop: this may be an acceptable trade-off in some cases with limited bandwidth, but it still is one
117 2013-12-21 09:41:22 <uiop> wumpus: what if nodes gave to their neighbors the bloom filter *itself*? would that not solve the information disclosure?
118 2013-12-21 09:41:41 <wumpus> IIRC that's exactly what they do
119 2013-12-21 09:41:51 <uiop> heh, oh
120 2013-12-21 09:41:56 <uiop> 
ACTION is still reading...

121 2013-12-21 13:54:32 <deanclkclk> folks
122 2013-12-21 13:54:34 <deanclkclk> question..is bitcoind json-rpc accessed over http or is it socket?
123 2013-12-21 14:07:52 <sipa> deanclkclk: http uses a socket...
124 2013-12-21 14:08:02 <sipa> but yes it is http
125 2013-12-21 14:08:29 <deanclkclk> sipa: I'm having a difficult problem trying to find a solution in java/spring
126 2013-12-21 14:08:34 <deanclkclk> nothing coherent
127 2013-12-21 14:08:48 <deanclkclk> everything on the net uses a different library and some deprecated
128 2013-12-21 14:42:18 <Alina-malina> how can i see the date and time of bitcoin that was rewarder to miner and miners some ID?
129 2013-12-21 14:52:47 <sipa> what id?
130 2013-12-21 14:53:14 <Alina-malina> I dont know, something
131 2013-12-21 14:54:27 <sipa> if you have an actual question, i might be able to answer :)
132 2013-12-21 14:55:45 <Alina-malina> sipa, i want to know when the block was generated and what time a coin was rewarder to miner, is it possible to see that information?
133 2013-12-21 14:58:35 <sipa> approximately, if you know which block
134 2013-12-21 14:59:09 <reCrypto> Hi guys. :)
135 2013-12-21 15:47:17 <Alina-malina> sipa, what other information i can retriee from bitcoin address?
136 2013-12-21 15:47:51 <Alina-malina> *retrieve
137 2013-12-21 15:47:53 <sipa> a block is not an address
138 2013-12-21 15:47:57 <Alina-malina> i understand
139 2013-12-21 15:48:06 <sipa> then what do you want?
140 2013-12-21 15:48:07 <Alina-malina> i am trying to gather as much informatoin as it is possible
141 2013-12-21 15:48:12 <sipa> about what?
142 2013-12-21 15:48:22 <Alina-malina> about bitcoin address, blockchain
143 2013-12-21 15:48:31 <Alina-malina> anything that is possible to know from address
144 2013-12-21 15:48:52 <sipa> do you want transactions to an address?
145 2013-12-21 15:49:08 <Alina-malina> that as well
146 2013-12-21 15:49:38 <sipa> i don't think you understand what you are looking for
147 2013-12-21 15:49:44 <Alina-malina> oh i understand
148 2013-12-21 15:49:48 <Alina-malina> for example
149 2013-12-21 15:50:28 <Alina-malina> Alice gave bob her bitcoin adress, bob wants to retrieve any possible informatoin from that address as much as he can, like when that address was created....
150 2013-12-21 15:50:49 <sipa> you cannot know when an address is created
151 2013-12-21 15:50:53 <Alina-malina> ok
152 2013-12-21 15:51:10 <Alina-malina> so the address doesnt contain any additional information?
153 2013-12-21 15:51:19 <Alina-malina> it is just a public key
154 2013-12-21 15:51:27 <sipa> an address is just a destination for transactions
155 2013-12-21 15:51:53 <Alina-malina> hmmmm
156 2013-12-21 15:52:14 <Alina-malina> even we cant see how much money have the wallet?
157 2013-12-21 15:52:18 <Alina-malina> of that address
158 2013-12-21 15:52:22 <Alina-malina> i mean bitcoins
159 2013-12-21 16:32:02 <petertodd> BlueMatt: re:bloom, oh yeah? is there a write-up of that math anywhere? I could use it for the darkwallet best practices document
160 2013-12-21 16:33:42 <ellisdenada> does anyone know if bitcoin-qt stores decrypted wallets in memory or actually writes to disk?
161 2013-12-21 16:33:53 <petertodd> BlueMatt: long-term it's likely the case that wallets should just always use prefix filters simply because it's easier to reason about the anonymity set if the false positive set stays consistent
162 2013-12-21 16:46:13 <sipa> ellisdenada: only in memory
163 2013-12-21 16:46:35 <ellisdenada> sipa: thanks
164 2013-12-21 16:51:49 <ellisdenada> another question: any disadvantage to storing the blockchain on an external HD (so that every time I boot up a clean instance of linux to do some work on a wallet, I don't have to wait 7 years for it to download)?
165 2013-12-21 16:53:35 <kuzetsa> ellisdenada: no disadvantage that I can think of
166 2013-12-21 16:55:30 <sipa> external hard drives are frequently less reliable (usb controllers, connection breaking down...)
167 2013-12-21 16:55:43 <sipa> so i think the chance for getting corruption would be worse
168 2013-12-21 17:03:16 <kuzetsa> hehe
169 2013-12-21 17:03:41 <kuzetsa> yeah, sure, there's that (corruption, slower access times if it's lower RPMs, reliability, etc.)
170 2013-12-21 17:04:54 <ellisdenada> it'd be nice to have some kind of local cache of the BC though
171 2013-12-21 17:05:39 <ellisdenada> 'cause this sync is taking a gazillion years
172 2013-12-21 17:06:28 <sipa> -dbcache=X
173 2013-12-21 17:06:35 <sipa> with X a number in megabytes
174 2013-12-21 17:06:59 <phantomcircuit> sipa, i did some basic benchmarking of ProcessBlock
175 2013-12-21 17:07:17 <phantomcircuit> afaict the version number checks where it looks 500 blocks back is using ~10% of the cpu time
176 2013-12-21 17:07:27 <sipa> wut?
177 2013-12-21 17:07:35 <phantomcircuit> seems like there is probably an easy optimization there ...
178 2013-12-21 17:07:49 <phantomcircuit> yeah i was kind of surprised by it also
179 2013-12-21 17:08:15 <phantomcircuit> shows how well everything else is optimized i guess
180 2013-12-21 17:08:17 <phantomcircuit> heh
181 2013-12-21 17:08:19 <sipa> perhaps with high dbcache and before sigchecks are enabled
182 2013-12-21 17:08:33 <phantomcircuit> yeah
183 2013-12-21 17:08:33 <sipa> but even then
184 2013-12-21 17:08:43 <phantomcircuit> definitely before sigchecks :)
185 2013-12-21 17:08:46 <sipa> the dbcache isn't even a hashmap
186 2013-12-21 17:08:49 <phantomcircuit> and with dbcache at4096
187 2013-12-21 17:09:00 <sipa> that'd be my first guess for optimizing things
188 2013-12-21 17:09:03 <phantomcircuit> sipa, lol what is it?
189 2013-12-21 17:09:11 <sipa> an stl::map
190 2013-12-21 17:09:16 <sipa> which is a tree map
191 2013-12-21 17:10:03 <phantomcircuit> sipa, AcceptBlock the block after "Enforce block.nVersion=2 rule that the coinbase starts with serialized block height"
192 2013-12-21 17:10:20 <phantomcircuit> im guessing the IsSuperMajority is the problem
193 2013-12-21 17:10:36 <sipa> that could very easily be optimized
194 2013-12-21 17:10:59 <sipa> just keep a count for each, that is updated on connect/disconnect
195 2013-12-21 17:13:12 <ellisdenada> sipa: is the github issue tracker best place to look for bugs to tackle?
196 2013-12-21 17:14:19 <sipa> probably, yeah
197 2013-12-21 17:14:30 <sipa> though i doubt many of them are actionable directly
198 2013-12-21 17:14:59 <sipa> phantomcircuit: what was the reason that removing vtxPrev could be a problem?
199 2013-12-21 17:15:25 <ellisdenada> basically just interested in contributing somehow... any advice on where to start?
200 2013-12-21 17:16:06 <sipa> helping to test things is probably the most useful
201 2013-12-21 17:16:09 <sipa> amd review code
202 2013-12-21 17:16:14 <nsh> mine's coffee, black, two sugars
203 2013-12-21 17:16:18 <nsh> thanks
204 2013-12-21 17:16:20 <nsh> (kiddin' on)
205 2013-12-21 17:16:30 <sipa> java coffee?
206 2013-12-21 17:16:34 <nsh> 
ACTION shudders

207 2013-12-21 17:16:41 <phantomcircuit> sipa, it wasn't removing vtxPrev but rather making IsConfirmed do what it says it does
208 2013-12-21 17:16:54 <phantomcircuit> there's no problem with removing vtxPrev since it doesn't do anything anyways
209 2013-12-21 17:17:16 <sipa> in what way doea isconfirmed not do what it says?
210 2013-12-21 17:17:19 <phantomcircuit> fixing IsConfirmed changed the behavior of the getbalance rpc call in weird ways such that it could report negative balances
211 2013-12-21 17:17:59 <phantomcircuit> sipa, it claims to tell you if a transaction is entirely dependent on outputs you control
212 2013-12-21 17:18:21 <phantomcircuit> but vtxPrev is always empty
213 2013-12-21 17:18:25 <phantomcircuit> so of course that doesn't work
214 2013-12-21 17:18:35 <sipa> vtxPrev is not always empty?
215 2013-12-21 17:18:54 <phantomcircuit> sipa, vtxPrev always contains nothing but default ctor CTransaction objects
216 2013-12-21 17:18:55 <sipa> it just only ever contains things that are in mapWallet to
217 2013-12-21 17:18:58 <phantomcircuit> so it's effectively always empty
218 2013-12-21 17:19:04 <sipa> huh?
219 2013-12-21 17:19:16 <sipa> really?
220 2013-12-21 17:19:20 <phantomcircuit> im pretty sure
221 2013-12-21 17:19:26 <phantomcircuit> i'll check again though
222 2013-12-21 17:19:29 <ellisdenada> nsh: hah
223 2013-12-21 17:19:38 <ellisdenada> where do you live? I'll fedex it
224 2013-12-21 17:20:36 <nsh> as long as you don't use UPS...
225 2013-12-21 17:20:44 <nsh> i have a very traumatic experience with UPS deliveries
226 2013-12-21 17:22:53 <phantomcircuit> sipa, huh it *looks* like vtxPrev should have those
227 2013-12-21 17:23:00 <phantomcircuit> but i distinctly remember them all being empty
228 2013-12-21 17:24:23 <phantomcircuit> sipa, weird you're right, so my replacement for the second half of IsConfirmed shouldn't change the behavior at all
229 2013-12-21 17:24:34 <phantomcircuit> but im pretty sure it does
230 2013-12-21 17:26:00 <sipa> nsh: same!
231 2013-12-21 17:26:08 <phantomcircuit> sipa, yeah actually looking at the patch i wasn't very careful
232 2013-12-21 17:26:17 <phantomcircuit> it doesn't acquire the mempool lock so it could totally break stuff
233 2013-12-21 17:26:56 <nsh> 
ACTION smiles

234 2013-12-21 17:27:32 <TheLordOfTime> is there a reason a tx wouldn't be picked up in the chain or be visible on blockchain.info or the blockexplorer, even after an hour?
235 2013-12-21 17:31:39 <phantomcircuit> TheLordOfTime, is it non standard
236 2013-12-21 17:32:01 <sipa> or low fees
237 2013-12-21 17:32:12 <sipa> or miners don't like you
238 2013-12-21 17:32:17 <sipa> or phase of the moon
239 2013-12-21 17:32:22 <TheLordOfTime> sipa: phantomcircuit: ultimately it isn't my tx, i'm asking for someone in -otc
240 2013-12-21 17:32:27 <TheLordOfTime> sipa: or those damn pesky cosmic rays
241 2013-12-21 17:32:35 <TheLordOfTime> they say there's two such transactions that're not being picked up at all
242 2013-12-21 17:32:36 <sipa> yeah, very nasty
243 2013-12-21 17:33:07 <phantomcircuit> TheLordOfTime, if they sent them from their own client then it's possible they aren't in sync and the resend wallet transactions function isn't working
244 2013-12-21 17:40:24 <TheLordOfTime> phantomcircuit: Ping in -otc from the one affected.
245 2013-12-21 17:40:43 <TheLordOfTime> ultimately though: [13/12/21 12:37:51] <kapiteined> TheLordOfTime: just the normal bitcoin-qt client if i look at the transaction details, the from and to address are the same.
246 2013-12-21 17:42:39 <phantomcircuit> from address?
247 2013-12-21 17:43:07 <phantomcircuit> pretty sure the client doesn't show a from address
248 2013-12-21 18:38:00 <Alina-malina> anyone please, if i generate valid bitcoin addresses offline how i can declare it to system that they are my?
249 2013-12-21 18:38:52 <gmaxwell> Alina-malina: there is no need to declar it to the system that they are yours. They simply are. Also, this is a question for #bitcoin feel free to ask further questions there (I'm in there too)
250 2013-12-21 18:49:39 <CodeShark> gmaxwell: are you checking pms?
251 2013-12-21 19:43:53 <gmaxwell> wtf saivann stuck google analytics on bitcoin.org with a direct commit instead of a pull req.
252 2013-12-21 19:51:08 <Plarkplark_> are 0 confirmed transactions safe? (to about 100USD worth)?
253 2013-12-21 19:51:32 <petertodd> Plarkplark_: no
254 2013-12-21 19:51:47 <petertodd> Plarkplark_: or yes if you trust the sender
255 2013-12-21 19:52:42 <Plarkplark_> How hard is it to fake?
256 2013-12-21 19:53:01 <Plarkplark_> does it require skill, money and computing power?
257 2013-12-21 19:53:02 <petertodd> Plarkplark_: easy
258 2013-12-21 19:53:12 <petertodd> Plarkplark_: just skill, or someone with skill to do it for you
259 2013-12-21 19:53:27 <Plarkplark_> So buying $1 cofee with btc requires you to wait?
260 2013-12-21 19:53:28 <petertodd> Plarkplark_: 1 confirm requires skill and money/computing power, lots of it
261 2013-12-21 19:53:59 <petertodd> Plarkplark_: no, because most people are honest enough that the % of assholes isn't a big deal
262 2013-12-21 19:54:01 <Plarkplark_> That I understand. But a 0 confirm is easy as in " script kiddie"  easy?
263 2013-12-21 19:54:15 <Plarkplark_> because bitpay takes 0 confirm
264 2013-12-21 19:54:21 <petertodd> Plarkplark_: there are *unmanned* coffee shops/bakeries out there that rely 100% on the honesty of their customers and they do just fine
265 2013-12-21 19:55:20 <petertodd> Plarkplark_: blockchain.info had a double-spend creator page awhile back, can't find it now but yeah, it's script-kiddie easy
266 2013-12-21 19:55:33 <petertodd> heck, I'll show you if you want...
267 2013-12-21 19:55:51 <Plarkplark_> Any way to fix this? Make 0 confirm at least economicly unfeasable?
268 2013-12-21 19:56:08 <Plarkplark_> because this is solid argument against bitcoin (by haters)
269 2013-12-21 19:56:43 <petertodd> Plarkplark_: yup, ironically by making double-spending zeroconf even easier: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
270 2013-12-21 19:57:47 <Plarkplark_> Because this is one of the arguments against adoption I find hard to fight. Litecoiners tend to use it as _the_ unique selling point
271 2013-12-21 19:57:54 <Plarkplark_> bleh
272 2013-12-21 19:59:08 <petertodd> Plarkplark_: meh, 2.5m *average* is a long time to wait too
273 2013-12-21 19:59:16 <Plarkplark_> So, double spending is "always"  without fee?
274 2013-12-21 19:59:25 <petertodd> Plarkplark_: and I say this as a guy who's actually fairly involved with litecoin development
275 2013-12-21 19:59:45 <petertodd> Plarkplark_: you sound like you have some misconceptions about how bitcoin works...
276 2013-12-21 20:00:08 <Plarkplark_> I thnk this needs to be a high priority on dev, imho. It's not a real technical problem but give somebody (as they say in my language) "A Hammer to hit with"
277 2013-12-21 20:00:27 <petertodd> meh, we've got real technical problems to solve
278 2013-12-21 20:00:28 <petertodd> bbl
279 2013-12-21 20:01:42 <Plarkplark_> ok true. well :)
280 2013-12-21 20:02:00 <Plarkplark_> thanks anyway. good info
281 2013-12-21 20:24:44 <CodeShark> the confirmation delay is a direct consequence of the CAP theorem
282 2013-12-21 20:41:30 <Hans-Martin> hi folks, does anyone know why the bitcoin-qt client does not show a menu bar in Ubuntu? This problem seems to have been fixed a while ago, but it has reappeared (don't remember with which client version)
283 2013-12-21 20:42:30 <kaptah> is there a chance this will get ever into a block / is it possible to make a second transaction with larger fee from one of the inputs for which I have private key (but not for all) ? https://blockchain.info/tx/0191a6651cc7ebbef04bcea6ff58844215c1a410eff8db55e40a83482f472c0f
284 2013-12-21 20:42:51 <kaptah> s/inputs/outputs
285 2013-12-21 20:54:40 <etotheipi_> gmaxwell: ping
286 2013-12-21 20:57:22 <andytoshi> kaptah: did you make that with createrawtransaction?
287 2013-12-21 20:57:40 <andytoshi> it is nonstandard, so it might not have propagated too far .. so there are some online pushtx services you can use
288 2013-12-21 20:58:05 <andytoshi> ;;bc,blocks
289 2013-12-21 20:58:06 <gribble> 276267
290 2013-12-21 20:58:26 <andytoshi> kaptah: or if you /msg me the rawtx i can broadcast it for you
291 2013-12-21 20:58:36 <kaptah> andytoshi: no, it's from "bitcoinmillions.com" to multiple recipients
292 2013-12-21 20:58:37 <andytoshi> (your local bitcoind will reject it because it won't do double-spends)
293 2013-12-21 20:59:21 <andytoshi> oh, i missed half your question
294 2013-12-21 20:59:27 <andytoshi> no, you cannot change it without all the privkeys, sorry
295 2013-12-21 20:59:38 <kaptah> andytoshi: ok thanks :/
296 2013-12-21 21:04:21 <andytoshi> if you just want to get your inputs out of there you can create a new transaction spending to one of your outputs
297 2013-12-21 21:04:27 <andytoshi> which will invalidate that tx for everyone else..
298 2013-12-21 21:08:00 <niston> there.
299 2013-12-21 21:08:02 <niston> hi all!
300 2013-12-21 21:08:22 <niston> is there something special with blocks 273304/273305 ?
301 2013-12-21 21:08:50 <niston> I'm using bitcoin-tool to parse the blockchain, and I'm getting an extraneous block there
302 2013-12-21 21:10:13 <niston> or, at least blockexplorercom doesn't agree with what I'm parsing
303 2013-12-21 21:11:55 <kaptah> andytoshi: Im one of the receiving addressess so I can't re-spent the input.
304 2013-12-21 21:14:11 <sipa> niston: a fork?
305 2013-12-21 21:14:32 <sipa> there can be multiple blocks with the same height, happebs all the time
306 2013-12-21 21:14:37 <sipa> *happens
307 2013-12-21 21:15:17 <niston> that's what I thought, and indeed there is. however, there are other forks, and bitcoin-tool doesn't produce an extra block, except @ 273304->273305
308 2013-12-21 21:15:33 <niston> so I'm a tad bit confused.
309 2013-12-21 21:16:18 <CodeShark> if it's any consolation, blockchain.info seems to be confused as well :)
310 2013-12-21 21:16:23 <CodeShark> https://blockchain.info/block-height/273304
311 2013-12-21 21:16:49 <CodeShark> or no, sorry
312 2013-12-21 21:16:58 <CodeShark> it's two different blocks - yeah, it's a fork
313 2013-12-21 21:17:26 <niston> how could I recognize this condition ?
314 2013-12-21 21:17:44 <niston> here's the info I have so far: http://pastebin.com/m4jYAJEd
315 2013-12-21 21:18:03 <niston> could I use the prev. block hash to recognize the fork?
316 2013-12-21 21:18:16 <CodeShark> yes
317 2013-12-21 21:18:26 <niston> the later being the valid one ?
318 2013-12-21 21:20:06 <CodeShark> looks like the former one is the main chain block
319 2013-12-21 21:20:08 <niston> or rather, the first occurence? comparing to blockexplorer, 273304 seems the legit one, while 273305 doesn't seem to exist and 273306 is really 273305 :)
320 2013-12-21 21:21:24 <niston> well let me try this and have a var for prev. hash, so as to ignore any second occurences
321 2013-12-21 21:21:50 <CodeShark> yeah, the block height should be calculated as prev block height + 1
322 2013-12-21 21:22:11 <niston> hmm.. what is this 'block height' ?
323 2013-12-21 21:22:27 <niston> the number ?
324 2013-12-21 21:22:41 <CodeShark> the genesis block has height 0, then all blocks afterwards in the main chain are numbered 1, 2, 3, ...
325 2013-12-21 21:22:49 <niston> ah okay :)
326 2013-12-21 21:23:22 <CodeShark> if you get two blocks with the same height, you have to keep constructing on both until one chain outgrows the other (is more difficult)
327 2013-12-21 21:23:56 <niston> how would that relate to bitcoin-qt blkXXX.dat files?
328 2013-12-21 21:24:28 <CodeShark> generally speaking, I would avoid directly touching those files
329 2013-12-21 21:24:55 <sipa> niston: all blocks are stored to disk, in the order thry are received
330 2013-12-21 21:25:08 <niston> alright, so the forks are stored, too.
331 2013-12-21 21:25:14 <sipa> just from the block dat files you cannot judge which ended up being accepted
332 2013-12-21 21:25:32 <CodeShark> yeah - the dead branches are never erased
333 2013-12-21 21:25:43 <niston> what confuses me then is that bitcoin-tool doesn't seem to produce any 'extra' blocks from earlier forks than 273304
334 2013-12-21 21:26:00 <CodeShark> your code has to have the logic to chain them together
335 2013-12-21 21:27:07 <CodeShark> niston, has this bitcoind instance been running for a long time? or did you just recently sync it up?
336 2013-12-21 21:27:16 <niston> about three weeks
337 2013-12-21 21:28:49 <niston> hmm 273304 falls within that time frame
338 2013-12-21 21:29:26 <niston> you mean to say it has only those forks on disk that it has 'seen live', so to speak ?
339 2013-12-21 21:29:32 <CodeShark> yeah
340 2013-12-21 21:30:03 <CodeShark> when it syncs, it asks other nodes only for their main chain blocks
341 2013-12-21 21:30:10 <niston> i see
342 2013-12-21 21:30:27 <niston> so when it gets them from the network, it has to do it's own validation
343 2013-12-21 21:30:33 <CodeShark> indeed
344 2013-12-21 21:30:34 <niston> but it won't erase them from the blk.dat
345 2013-12-21 21:30:38 <CodeShark> correct
346 2013-12-21 21:31:22 <niston> does bitcoind store validation information in some file that I could parse?
347 2013-12-21 21:33:25 <CodeShark> what are you trying to do?
348 2013-12-21 21:33:43 <niston> following the block chain, basically.
349 2013-12-21 21:34:28 <CodeShark> then just follow all branches until one dies
350 2013-12-21 21:34:37 <CodeShark> then continue following the live ones
351 2013-12-21 21:35:40 <CodeShark> at each height, you might have one or more live branches - eventually, all of them will die but one
352 2013-12-21 21:36:52 <niston> alright, that cleared up things quite a lot. thank you :)
353 2013-12-21 21:37:04 <CodeShark> in theory, you should actually compute the total work rather than just the height to select which branches live…but in practice, I don't think there's an example where just following the height gives you the wrong answer
354 2013-12-21 21:37:49 <niston> yes, as I understand, impossible blocks (where the proof-of-work doesn't validate) would not be distributed across the network?
355 2013-12-21 21:38:23 <CodeShark> you could have two chains where one has greater height but the other is more difficult (at least in principle)
356 2013-12-21 21:38:39 <CodeShark> this would be due to different retargetting in each
357 2013-12-21 21:38:55 <niston> ah I see. such as an attacker tries to insert blocks made with a lower difficultiy?
358 2013-12-21 21:39:04 <CodeShark> right
359 2013-12-21 21:39:44 <CodeShark> but that could only happen if an attacker managed to convince you to retarget higher than the actual main chain
360 2013-12-21 21:40:05 <niston> retargeting means?
361 2013-12-21 21:40:20 <CodeShark> changing the block difficulty (which happens every 2016 blocks)
362 2013-12-21 21:40:26 <niston> ah
363 2013-12-21 21:40:37 <niston> so that's theoretical cause that wouldnt exactly benefit an attacker then
364 2013-12-21 21:40:53 <CodeShark> in practice it's difficult to exploit
365 2013-12-21 21:41:13 <niston> she could only insert blocks with a difficulty higher than main
366 2013-12-21 21:41:27 <niston> which is, well, probably not what she wants :)
367 2013-12-21 21:42:35 <CodeShark> well, if an attacker deprives you from knowing about blocks that have already been mined and only feeds you his/her blocks at a much slower rate, at the next multiple of 2016 blocks your node will think the difficulty is lower than it really is
368 2013-12-21 21:43:02 <niston> but that's almost impossible if I keep more than one connection to the network, right ?
369 2013-12-21 21:43:24 <CodeShark> yeah, connecting to multiple nodes helps mitigate this risk
370 2013-12-21 21:43:33 <niston> since the other linked nodes would inform me about the block being mined
371 2013-12-21 21:43:46 <CodeShark> correct
372 2013-12-21 21:44:19 <CodeShark> an attack is still possible in principle when nearing a multiple of 2016
373 2013-12-21 21:44:44 <niston> how so ?
374 2013-12-21 21:45:29 <CodeShark> the attacker can move the timestamp forward up to a couple hours
375 2013-12-21 21:46:44 <CodeShark> the new target is computed from the difference in timestamp between the first and last blocks of each 2016 batch
376 2013-12-21 21:47:03 <niston> ah
377 2013-12-21 21:47:20 <niston> so a wrong difficulty would be computed
378 2013-12-21 21:47:52 <niston> lower than it actually is, because the timespan would seem longer
379 2013-12-21 21:48:17 <CodeShark> right - however, two hours out of two weeks is not a whole lot of difference
380 2013-12-21 21:48:37 <niston> true, even more so as difficulty continues to rise to soaring heights
381 2013-12-21 21:49:08 <niston> well at least there's something going "to da moon", hehe
382 2013-12-21 21:56:19 <niston> I'll be off to code some more, thanks for the little discussion and info, CodeShark!
383 2013-12-21 21:57:07 <CodeShark> cheers :)
384 2013-12-21 22:00:51 <Intelftw> Hello, I'm trying to understand stratum protocol from http://mining.bitcoin.cz/stratum-mining and I don't get how merkle root is generated. There is python snippet that shows how to generate merkle tree but it's not a tree it just hashes each branch with previous one. Can somebody explain me this?
385 2013-12-21 22:07:15 <keyboard> It can be a tree where branches are one short
386 2013-12-21 22:08:24 <sipa> Intelftw: that's a merkle tree
387 2013-12-21 22:08:37 <sipa> Intelftw: every node is the hash of two nodes at the previous level together
388 2013-12-21 22:09:03 <sipa> ah, i get it
389 2013-12-21 22:09:14 <sipa> so, assume you have a block with 7 transactions
390 2013-12-21 22:09:18 <sipa> you have to add the coinbase
391 2013-12-21 22:09:34 <sipa> so you have transactions C, T1, T2, T3, T4, T5, T6, T7
392 2013-12-21 22:09:47 <sipa> the T's are determined by the pool, C comes from you
393 2013-12-21 22:10:16 <sipa> the second level of the tree would be H(C,T1), H(T2,T3), H(T4,T5), H(T6,T7)
394 2013-12-21 22:10:18 <sipa> Intelftw: agree?
395 2013-12-21 22:10:26 <Intelftw> ye
396 2013-12-21 22:11:25 <sipa> let's call H(T2,T3) = T23, ... ok?
397 2013-12-21 22:11:57 <sipa> so the level above that would be H(H(C,T1),T23), T4567
398 2013-12-21 22:12:12 <sipa> and the level above that is H(H(H(C,T1),T23),T4567)
399 2013-12-21 22:12:34 <sipa> so the pool sends you T1, T23 and T4567 precomputed
400 2013-12-21 22:12:49 <sipa> and you only have the recompute the leftmost branch of the tree, as only C changes
401 2013-12-21 22:12:55 <jacob___> HI, there are to nets "bitcoin" and "testnet3"
402 2013-12-21 22:13:02 <Intelftw> ah i c
403 2013-12-21 22:13:02 <sipa> jacob___: correct
404 2013-12-21 22:13:11 <sipa> jacob___: the first one is often called mainnet or realnet
405 2013-12-21 22:13:17 <Intelftw> I though pool sends t1 t2 t3 etc
406 2013-12-21 22:13:22 <Intelftw> thanks
407 2013-12-21 22:13:26 <jacob___> what does the hash '\xf9','\xbe','\xb4','\xd9' mean?
408 2013-12-21 22:13:40 <sipa> that's not a hash, it's a list of bytes
409 2013-12-21 22:13:41 <jacob___> I am looking at jgarzik code "picocoin"
410 2013-12-21 22:13:50 <sipa> and it's the magic network identifier
411 2013-12-21 22:13:58 <jacob___> the not nets have "netmagics"?
412 2013-12-21 22:13:59 <sipa> it's prefixed to all network packets
413 2013-12-21 22:14:06 <sipa> not nets?
414 2013-12-21 22:14:26 <jacob___> ooops typo
415 2013-12-21 22:14:40 <jacob___> delete "not"
416 2013-12-21 22:14:51 <sipa> every network has its own magic
417 2013-12-21 22:15:13 <sipa> it's to prevent accidentally wrong connections to be incorrectly interpreted
418 2013-12-21 22:15:21 <jacob___> excellent
419 2013-12-21 22:16:16 <Intelftw> sipa: What if I have 9 transactions? Then I treat T10-T16 as T9 ?
420 2013-12-21 22:16:28 <sipa> Intelftw: draw it
421 2013-12-21 22:22:51 <phantomcircuit> sipa, oh if only they really all had their own magic...
422 2013-12-21 22:23:13 <sipa> phantomcircuit: both _bitcoin_ networks do :)
423 2013-12-21 22:23:50 <phantomcircuit> there's at least one altcoin that's using the mainnet magic value
424 2013-12-21 22:24:19 <sipa> i had an altcoin author contact me once, because they cloned another altcoin without changing magic and p2p port
425 2013-12-21 22:24:33 <sipa> and there chains tried to compete/overwrite eachother
426 2013-12-21 22:24:35 <sipa> epic fun
427 2013-12-21 22:24:41 <sipa> their
428 2013-12-21 22:26:12 <phantomcircuit> lol
429 2013-12-21 22:28:13 <nsh> oh, that would be an interesting experiment...
430 2013-12-21 22:29:11 <nsh> some kinda blockchain analogue of corewars with mutating various protocol/parameters of a simplified bitcoind to see which version can overwrite the most of the others
431 2013-12-21 22:29:34 <Intelftw> sipa, one thing is still not clear for me. If I have 5 transactions (C is T1) according to bitcoin wiki I have to add T6=T5 to make it even. So then right branch is H(H(T5 + T6) + H(T6 + T6)) or H(H(T5 + T6) + H(T6)) ?
432 2013-12-21 22:29:39 <Intelftw> sorry for dumb questions
433 2013-12-21 22:35:38 <sipa> Intelftw: lowest branch is t1,t2,t3,t4,t5
434 2013-12-21 22:35:51 <sipa> level above is t12, t34, t55
435 2013-12-21 22:36:09 <sipa> level above that is t1234, t5555
436 2013-12-21 22:36:17 <Synthetisoft> I'm looking to hire developers (Javascript & Desktop Devs) for a project. PM me if interested. I am funded.
437 2013-12-21 22:36:18 <sipa> level above that is t123455555
438 2013-12-21 22:36:48 <sipa> if it's 6
439 2013-12-21 22:37:11 <Intelftw> I get it now, thanks
440 2013-12-21 22:37:17 <Luke-Jr> sipa: what are your thoughts on some kind of RII where the subkey id is determined by height rather than iteration?
441 2013-12-21 22:37:28 <Luke-Jr> sipa: for stateless mining stuff :P
442 2013-12-21 22:37:46 <Synthetisoft> We pay good at our company and can provide proof. We are just having a had time finding bitcoin devs
443 2013-12-21 22:38:19 <jacob___> Synthetisoft:  work remotely?
444 2013-12-21 22:38:24 <Luke-Jr> Synthetisoft: because everyone with a clue is busy ;)
445 2013-12-21 22:38:24 <Synthetisoft> yes
446 2013-12-21 22:38:39 <Synthetisoft> We do our hiring through Odesk
447 2013-12-21 22:38:41 <sipa> Synthetisoft: no offence, but now you sound like http://xkcd.com/1293/ :)
448 2013-12-21 22:39:13 <sipa> (not commenting on whether you're trustworthy or not, just reminding me of it)
449 2013-12-21 22:39:49 <sipa> Luke-Jr: i don't see a problem with designating a branch somewhere for that
450 2013-12-21 22:40:12 <sipa> Luke-Jr: the whole specific-tree-structures-for-more-than-just-sequential-keys is very blurry
451 2013-12-21 22:41:52 <sipa> on the other hand, forcing every wallet to support every exoting derivation structure people come up with...
452 2013-12-21 22:42:43 <sipa> s/exoting/exotic/
453 2013-12-21 22:44:25 <Luke-Jr> is it so exotic? :P
454 2013-12-21 22:44:36 <Synthetisoft> Look up apphoney on Odesk. I've spent well over 100k there in the past few month
455 2013-12-21 22:44:41 <nsh> sipa, just let the wallet dynamically include some remote code for key derivation that's hosted on whatever random website. it'll be fine...
456 2013-12-21 22:45:20 <sipa> Synthetisoft: i'm not sure whether here is the right place to look for people... most seem to know pretty well what to work on already (but i may be wrong, of course)
457 2013-12-21 22:45:48 <nsh> Synthetisoft, boy was that an unfortunate choice of monikor... trust me, i'm a-phoney...
458 2013-12-21 22:48:12 <nsh> (:-)
459 2013-12-21 23:05:46 <niston> mmh.. coffe-and-cuban-cigar break. yay!
460 2013-12-21 23:18:23 <wyager> Are the forums broken?
461 2013-12-21 23:18:36 <wyager> I can't seem to reply to a post
462 2013-12-21 23:19:23 <nsh> s/broken/fixed/
463 2013-12-21 23:19:54 <wyager> As of the last 5 seconds?
464 2013-12-21 23:28:33 <nsh> wyager, no, i was making a silly joke :)
465 2013-12-21 23:28:42 <wyager> Oh hahaha
466 2013-12-21 23:28:52 <wyager> :p
467 2013-12-21 23:29:35 <wyager> gmaxwell: If you're interested, I wrote an implementation of the draft BIP for encrypted HD wallets
468 2013-12-21 23:30:00 <wyager> With date support :p