1 2014-01-20 00:33:33 <nsh> <perhapstired> Does the bitcoin-qt client always select from the oldest input and the oldest address when sending bitcoin?
  2 2014-01-20 00:34:15 <sipa> no
  3 2014-01-20 00:34:32 <sipa> it picks whatever it can use, though it prefers coins that have 6 confirmations or more
  4 2014-01-20 00:39:50 <d33tah> hi fellows
  5 2014-01-20 00:39:56 <d33tah> the current git version crashes for me:
  6 2014-01-20 00:39:59 <d33tah> bitcoin-qt: key.cpp:134: {anonymous}::CECKey::CECKey(): Assertion `pkey != __null' failed.
  7 2014-01-20 00:40:13 <d33tah> compiled with noncompatible db, asked me for data directory, chose defaults, it crashed with SIGABRT.
  8 2014-01-20 00:40:17 <d33tah> fedora 20.
  9 2014-01-20 00:43:34 <Luke-Jr> nsh: "oldest address"?
 10 2014-01-20 00:43:47 <nsh> (no idea)
 11 2014-01-20 00:43:53 <nsh> (copied from #bitcoin)
 12 2014-01-20 00:44:02 <phantomcircuit> Luke-Jr, he means oldest output i assume
 13 2014-01-20 00:44:15 <phantomcircuit> which isn't entirely illogical due to the way tx fees are calculated
 14 2014-01-20 00:45:37 <sipa> d33tah: you're linked against a fedora openssl that doesn't have support for the secp256k1 curve that bitcoin uses
 15 2014-01-20 00:45:59 <d33tah> sipa: i see. thanks for info.
 16 2014-01-20 00:46:04 <d33tah> that sucks. :/
 17 2014-01-20 00:46:17 <d33tah> could this error message be made a bit more verbose?
 18 2014-01-20 00:48:50 <sipa> there's openssl packages that provide that curve
 19 2014-01-20 00:49:07 <sipa> but i don't know much about fedora
 20 2014-01-20 00:49:28 <Luke-Jr> I do agree a better error message would be nice, though :P
 21 2014-01-20 00:49:48 <sipa> yeah
 22 2014-01-20 00:49:54 <sipa> should be easy to do
 23 2014-01-20 01:14:45 <SpartanLB> Wow
 24 2014-01-20 01:14:49 <SpartanLB> registering is a pain in the butt
 25 2014-01-20 01:16:29 <d33tah> guys
 26 2014-01-20 01:16:31 <d33tah> just wondering
 27 2014-01-20 01:16:49 <d33tah> i wanna copy my encrypted wallet, with all the addreses but one
 28 2014-01-20 01:17:13 <d33tah> is it going to be simplest to just set up a new encrypted wallet and transfer the money there?
 29 2014-01-20 01:17:18 <Luke-Jr> need some assistance
 30 2014-01-20 01:17:33 <Luke-Jr> sent a transaction, rather large, via RPC sendmany; got an error, but can't see the message
 31 2014-01-20 01:17:43 <Luke-Jr> the wallet has the transaction, and gettransaction works
 32 2014-01-20 01:17:51 <Luke-Jr> but getrawtransaction does not, and it seems to not have been relayed
 33 2014-01-20 01:18:01 <d33tah> and about the new wallets - they start off unencrypted, right? if i encrypt my wallet, will the private keys leak to the filesystem?
 34 2014-01-20 01:18:54 <Luke-Jr> 2014-01-20 01:16:48 ERROR: CTxMemPool::accept() : ignoring transaction 967a97276d2d07055017180f08c92fc7465b2dc222bc36489de8bd35476711d5 with blacklisted output (CHBS)
 35 2014-01-20 01:18:55 <Luke-Jr> doh
 36 2014-01-20 01:18:57 <Luke-Jr> nm
 37 2014-01-20 01:19:00 <sipa> d33tah: when you encrypt a wallet, its keypool is flushed
 38 2014-01-20 01:19:19 <sipa> d33tah: so all new keys you get afterwards are ones that never touched disk in unencrypted form
 39 2014-01-20 01:19:40 <d33tah> sipa: and the ones that were there already?
 40 2014-01-20 01:19:51 <sipa> those remain, obviously
 41 2014-01-20 01:19:58 <d33tah> i mean, doesn't the wallet start with some keys?
 42 2014-01-20 01:20:05 <sipa> yes
 43 2014-01-20 01:20:16 <d33tah> so i need to remove them.
 44 2014-01-20 01:20:20 <sipa> why
 45 2014-01-20 01:20:31 <sipa> did anyone send money to them?
 46 2014-01-20 01:20:53 <d33tah> noone did
 47 2014-01-20 01:21:01 <d33tah> but i'd not risk using an unencrypted key
 48 2014-01-20 01:21:13 <sipa> did you use any of these addresses?
 49 2014-01-20 01:21:18 <d33tah> didn't
 50 2014-01-20 01:21:20 <sipa> did you even *see* any of those addresses?
 51 2014-01-20 01:21:29 <d33tah> not sure, because we're theorizing atm.
 52 2014-01-20 01:21:46 <sipa> if you create a new wallet, and don't use it for anything, and then encrypt it, there is no risk
 53 2014-01-20 01:21:56 <d33tah> i see. thanks.
 54 2014-01-20 01:22:05 <d33tah> btw, sipa, are you one of the core devs?
 55 2014-01-20 01:22:07 <sipa> yes
 56 2014-01-20 01:22:11 <d33tah> bitcoin.org has an issue.
 57 2014-01-20 01:22:20 <d33tah> i mailed Gavin about it already
 58 2014-01-20 01:22:46 <sipa> what's the problem?
 59 2014-01-20 01:23:00 <sipa> (not that i'm involved with the website in any way)
 60 2014-01-20 01:23:02 <d33tah> sipa: the issue is that you can't really check the checksums of the archives over SSL. there's no HTTPS website linked.
 61 2014-01-20 01:23:12 <Luke-Jr> …
 62 2014-01-20 01:23:15 <sipa> well aware
 63 2014-01-20 01:23:18 <Luke-Jr> d33tah: SSL is worthless in this case anyway
 64 2014-01-20 01:23:22 <sipa> but you can check the GPG signatures
 65 2014-01-20 01:23:31 <d33tah> sipa: if i have them imported.
 66 2014-01-20 01:23:41 <Luke-Jr> if you want to verify the binaries, check the GPG sigs from all the devs who built it
 67 2014-01-20 01:23:54 <d33tah> and where would i safely get the keys from?
 68 2014-01-20 01:24:06 <Luke-Jr> Miami conference, next weekend
 69 2014-01-20 01:24:11 <sipa> haha
 70 2014-01-20 01:24:27 <d33tah> wish you held one in Poland.
 71 2014-01-20 01:24:30 <sipa> yes, it's a good question, and having https would certainly provide some value
 72 2014-01-20 01:24:45 <sipa> but it wouldn't protect against a hacked webserver
 73 2014-01-20 01:24:54 <d33tah> not against hacked webserver
 74 2014-01-20 01:24:58 <d33tah> my scenario is mitm
 75 2014-01-20 01:25:18 <petertodd> d33tah: think your computer is secure?
 76 2014-01-20 01:25:39 <d33tah> petertodd: above average.
 77 2014-01-20 01:25:54 <d33tah> i'm not delusional, but it doesn't mean i should give up stuff.
 78 2014-01-20 01:26:12 <d33tah> it feels awkward to pull an archive over HTTP and not even know how to verify if i was mitmed.
 79 2014-01-20 01:26:22 <petertodd> d33tah: small chicken and egg problem, but I've got copies of the dev's PGP keys timestamped from a year ago
 80 2014-01-20 01:26:30 <petertodd> d33tah: bitcoin timestamped of course :)
 81 2014-01-20 01:26:37 <Luke-Jr> d33tah: what makes you trust your computer's SSL CA certs? ;)
 82 2014-01-20 01:27:09 <d33tah> Luke-Jr: it's a different problem. the problem is - how harder is it for anyone on the wire to fake stuff if they're over SSL.
 83 2014-01-20 01:27:16 <d33tah> SSL is not the silver bullet, but it's better than plaintext.
 84 2014-01-20 01:27:32 <petertodd> d33tah: also, since you think your comptuer is secure, use the PGP WoT against one of the keys it came with, IE debian keyring
 85 2014-01-20 01:27:36 <Luke-Jr> d33tah: IMO it's a false sense of security in this case
 86 2014-01-20 01:27:59 <d33tah> petertodd: fedora doesn't have bitcoin in its repos
 87 2014-01-20 01:28:12 <Luke-Jr> …
 88 2014-01-20 01:28:19 <petertodd> d33tah: no, I mean from any PGP key it comes from, you can use WoT
 89 2014-01-20 01:28:22 <d33tah> Luke-Jr: atm anyone on the wire can change the data. over SSL it's not that trivial
 90 2014-01-20 01:28:37 <Luke-Jr> d33tah: Fedora probably has signed Jeff Garzik's key, who has probably signed some other devs, one of whom likely built the release
 91 2014-01-20 01:28:46 <petertodd> d33tah: e.g. if you have a copy of the Linux source, going from those devs to a bitcoin dev is pretty easy
 92 2014-01-20 01:28:54 <SpartanLB> LO
 93 2014-01-20 01:28:57 <Luke-Jr> hmm odd, I don't actually have a PGP key for Jeff at all O.o
 94 2014-01-20 01:28:59 <SpartanLB> people are talking its a miracle
 95 2014-01-20 01:29:09 <d33tah> SpartanLB: sorry about that.
 96 2014-01-20 01:29:29 <d33tah> so, basically, Luke-Jr
 97 2014-01-20 01:29:34 <SpartanLB> Soo are you guys all minerx
 98 2014-01-20 01:29:36 <SpartanLB> miners
 99 2014-01-20 01:29:55 <d33tah> you're saying that SSL on bitcoin.org is a bad idea because it gives false sense of security, which makes people too confident?
100 2014-01-20 01:30:02 <Luke-Jr> SpartanLB: off-topic, #bitcoin-mining
101 2014-01-20 01:30:11 <Luke-Jr> d33tah: debatable
102 2014-01-20 01:30:12 <SpartanLB> this is -dev though
103 2014-01-20 01:30:19 <Luke-Jr> SpartanLB: -dev is not -mining
104 2014-01-20 01:31:01 <petertodd> d33tah: e.g. http://pgp.cs.uu.nl/mk_path.cgi?FROM=79be3e4300411886&TO=1FC730C1&PATHS=trust+paths
105 2014-01-20 01:31:07 <d33tah> Luke-Jr: with SSL, the only way to take over is by taking over the CA. it kind of raises the bar.
106 2014-01-20 01:31:17 <licnep> when configuring i'm getting "configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)" is it safe to use --with-incompatible-bdb?
107 2014-01-20 01:31:27 <petertodd> lol, fake gavin code signing key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFC0271641F281E36
108 2014-01-20 01:31:30 <d33tah> petertodd: cool thing, thanks!
109 2014-01-20 01:32:06 <SpartanLB> no one in the mining chat is talking
110 2014-01-20 01:32:07 <gribble> Error: "," is not a valid command.
111 2014-01-20 01:32:07 <SpartanLB> ,,,
112 2014-01-20 01:32:13 <SpartanLB> ...
113 2014-01-20 01:33:18 <Luke-Jr> Bitcoin is too expensive, I just paid $20 in fees XD
114 2014-01-20 01:33:40 <Luke-Jr> d33tah: taking over *any* CA. not that hard.
115 2014-01-20 01:33:55 <d33tah> Luke-Jr: if you're government.
116 2014-01-20 01:34:12 <petertodd> d33tah: bitcointalk suffered a CA-related compromise not too long ago
117 2014-01-20 01:34:25 <d33tah> interesting.
118 2014-01-20 01:34:28 <Luke-Jr> licnep: just be aware the wallet it accesses will not work with official release binaries
119 2014-01-20 01:35:16 <petertodd> d33tah: it's not just governments that make the CA model insecure, it's that CA's will issue certs on incredibly little evidence
120 2014-01-20 01:35:42 <licnep> Luke-Jr: i see, thanks
121 2014-01-20 01:40:15 <d33tah> petertodd: wish there was an alternative.
122 2014-01-20 01:40:41 <petertodd> d33tah: trust is hard - it's not a problem solvable with just cryptography
123 2014-01-20 01:41:10 <d33tah> petertodd: interesting thought.
124 2014-01-20 01:41:26 <d33tah> anyway, gotta go to sleep, 2:41am here. goodnight guys!
125 2014-01-20 01:41:40 <sipa> sounds like a plan
126 2014-01-20 01:41:48 <sipa> same time here
127 2014-01-20 01:42:01 <d33tah> sipa: CEST, right? which country?
128 2014-01-20 01:42:09 <sipa> switzerland
129 2014-01-20 01:42:16 <d33tah> i see.
130 2014-01-20 01:42:39 <d33tah> and CET, not CEST*
131 2014-01-20 01:42:42 <d33tah> anyway
132 2014-01-20 01:42:44 <d33tah> bye for now
133 2014-01-20 01:47:26 <witten> does bitcoin currently support including additional metadata in a transaction, such that the transaction will still get relayed and mined? (the data doesn't need to end up in the blockchain, just relayed)
134 2014-01-20 01:47:46 <Luke-Jr> witten: not anymore.
135 2014-01-20 01:47:55 <witten> I can find lots of threads about BIP 16, P2SH, etc, but it's hard to tell what's currently implemented and what's just proposed
136 2014-01-20 01:48:00 <Luke-Jr> witten: it used to, but turned out to be a vulnerability
137 2014-01-20 01:48:16 <witten> Luke-Jr: for scripts? or for any metadata?
138 2014-01-20 01:48:21 <Luke-Jr> witten: metadata
139 2014-01-20 01:48:25 <witten> darn
140 2014-01-20 01:48:30 <Luke-Jr> witten: you used to be able to append anything to the end, and get it relayed
141 2014-01-20 01:48:39 <petertodd> witten: 32MB worth!
142 2014-01-20 01:48:43 <Luke-Jr> witten: the upcoming payment protocol provides a transport for metadata, but not p2p
143 2014-01-20 01:48:45 <witten> wow
144 2014-01-20 01:49:09 <petertodd> witten: quite seriously, for that use-case where the data *not* getting relayed occasionally isn't a disaster, consider using bitmessage
145 2014-01-20 01:49:28 <witten> thanks, I'll look into that
146 2014-01-20 02:08:19 <phantomcircuit> petertodd, i have yet to see anything where bitmessage was significantly safer than alternatives
147 2014-01-20 02:08:31 <phantomcircuit> what's the use case?
148 2014-01-20 02:10:44 <witten> I'm trying to broadcast proof of data possession challenges (~256 bytes), and my initial thought was to ride atop bitcoin transactions
149 2014-01-20 02:10:50 <witten> sounds like that's not going to work
150 2014-01-20 02:19:25 <phantomcircuit> witten, bitmessage is probably a reasonable solution for that
151 2014-01-20 02:19:50 <interdpth> Hi, I'm encountering configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)
152 2014-01-20 02:19:50 <interdpth> , is it fine to compile with incompatible bdb? I am compiling the daemon and not a QT wallet
153 2014-01-20 02:20:40 <saivann> I plan to merge this pull request in the following days:
154 2014-01-20 02:20:44 <saivann> https://github.com/bitcoin/bitcoin.org/pull/271
155 2014-01-20 02:20:48 <saivann> (Adding Coinkite to web wallets on bitcoin.org)
156 2014-01-20 02:20:54 <saivann> Please comment on the pull request if you have any questions / reservations
157 2014-01-20 02:21:06 <licnep> bitmessage has nothing to do with bitcoin right?
158 2014-01-20 02:21:31 <sipa> interdpth: do you need a wallet at all?
159 2014-01-20 02:23:33 <justanotheruser> licnep: same network topology to my understanding
160 2014-01-20 02:28:04 <interdpth> yeah
161 2014-01-20 02:28:13 <interdpth> guess I'll get this older one installed then :p
162 2014-01-20 02:59:55 <licnep> what's the current block count for the testnet?
163 2014-01-20 03:01:09 <licnep> nvm, 168570
164 2014-01-20 03:21:31 <aegis> Hi all, does anyone else have a problem with Bitcoin Armory giving Segmentation Fault (Core Dumped) errors and crashing in linux?
165 2014-01-20 03:23:43 <aegis> Anyone?
166 2014-01-20 03:26:13 <justanotheruser> aegis: run valgrind on it. That's all I would know to try
167 2014-01-20 03:26:55 <aegis> justanotheruser: thanks...  I've never heard of valgrind... will research
168 2014-01-20 03:28:06 <aegis> It does this on two different systems and both result with the same errors multiple times a day.
169 2014-01-20 03:28:37 <justanotheruser> aegis: valgrind tells you why it is getting a segfault
170 2014-01-20 03:29:22 <aegis> justanotheruser: installing it now...