1 2015-06-10 01:39:57 <chmod755> is Elements using a new testnet or is it the same testnet bitcoin core uses?
2 2015-06-10 01:41:25 <moa> chmod755: same testnet
3 2015-06-10 04:25:58 <fanquake> Can someone link me the 0.11.0rc1 gitian signature
4 2015-06-10 04:31:12 <phantomcircuit> fanquake, https://github.com/bitcoin/gitian.sigs
5 2015-06-10 04:32:49 <fanquake> phantomcircuit I mean the .tar.gz used to create the signed osx binary. It's on http://bitcoincore.org/ just can't remember where.
6 2015-06-10 04:33:36 <phantomcircuit> fanquake, not sure what you're asking for then
7 2015-06-10 04:33:44 <phantomcircuit> maybe you mean the signature from wumpus ?
8 2015-06-10 04:33:45 <phantomcircuit> https://github.com/bitcoin/gitian.sigs/tree/master/0.11.0rc1-osx-signed
9 2015-06-10 04:34:00 <fanquake> It's alright, got it https://bitcoincore.org/cfields/bitcoin-0.11.0rc1/signature.tar.gz
10 2015-06-10 06:11:57 <wumpus> fanquake: we're working on a repository with those detached signatures, https://github.com/bitcoin/bitcoin-detached-sigs (but it's still empty at this point, you have the right link)
11 2015-06-10 06:40:49 <fanquake> wumpus Good plan.
12 2015-06-10 07:12:23 <wumpus> PRab: seems redundant to start the paymentserver if the wallet is disabled
13 2015-06-10 07:13:36 <jonasschnelli> Agreed. Payment server should be disabled if wallte is not enabled. Maybe an issue for Diapolo?
14 2015-06-10 09:42:34 <bad_duck> "The issue of moving the mailinglist has come up before a few times and people can't agree where to move to." <-- it's not that hard to install a mainmal instance on a dedicated host, if needed I can help
15 2015-06-10 09:46:02 <phantomcircuit> bad_duck, that has never been the issue :P
16 2015-06-10 09:49:45 <bad_duck> phantomcircuit: so what's the issue?
17 2015-06-10 09:51:08 <wumpus> thanks for your offer bad_duck. Although it'd be one more server to babysit, which slightly worries me (sourceforge, for all its problems, has been reliable in keeping the thing running)
18 2015-06-10 09:51:37 <wumpus> most salient issue with sf is with signed mails and the advertisement crap they add making the messages invalid
19 2015-06-10 09:53:27 <wumpus> for the bitcoin-security mailing list the annoyance is the moderation; no "require sender to confirm their mail" feature, so there's lots of spam we need to sift through manually
20 2015-06-10 09:55:32 <bad_duck> for signed mails you don't really have the choice when the mailing software change headers (reply to) and send email from someone else (without proper spf record), so that's not really a sf issue but crappy ads yes that sucks
21 2015-06-10 09:56:59 <phantomcircuit> bad_duck, the signature is over the body of the email
22 2015-06-10 09:57:05 <phantomcircuit> which sf breaks by inserting ads into
23 2015-06-10 09:57:33 <bad_duck> I could propose to host the ML (I have a dedicated VM to host bitcoin stuffs, like a node and a explorer), but problem is there must be a fallback server somewhere else
24 2015-06-10 10:04:07 <petertodd> wumpus: signatures invalid? PGP or DKIM? the way it adds ads doesn't make PGP sigs invalid
25 2015-06-10 10:05:03 <bad_duck> with PGP no problem
26 2015-06-10 10:05:41 <wumpus> petertodd: not for PGP, but the other scheme (this e.g. causes messages from jgarzik to end up in spam folder sometimes)
27 2015-06-10 10:06:01 <wumpus> petertodd: it can be that I'm misremembering this issue though
28 2015-06-10 10:11:28 <petertodd> wumpus: sounds about right
29 2015-06-10 10:18:41 <wallet42> can I set datadir via some ENV ?
30 2015-06-10 10:20:02 <wumpus> only from a config file or command line argument
31 2015-06-10 10:26:06 <wumpus> can anyone that uses pruning test https://github.com/bitcoin/bitcoin/pull/6221 ? I think it's reasonably important, also for 0.11rc2
32 2015-06-10 10:27:32 <phantomcircuit> wumpus, is there anybody qualified to run those tests that uses pruning?
33 2015-06-10 10:27:34 <phantomcircuit> i doubt it
34 2015-06-10 10:28:22 <wumpus> qualified? as in "has a bitcoin-running-tests certification or diploma"?
35 2015-06-10 10:28:59 <wumpus> ideally someone that has the issue tests it and notices that it goes away
36 2015-06-10 10:29:11 <wumpus> (or not, in which case we've also learned something)
37 2015-06-10 10:30:06 <moa> what would be the exhibited behaviour?
38 2015-06-10 10:30:17 <phantomcircuit> wumpus, as in someone who can mess with the block files to trigger that behavior
39 2015-06-10 10:30:40 <wumpus> moa: https://github.com/bitcoin/bitcoin/issues/6184
40 2015-06-10 10:30:45 <moa> I was playing around with pruning on a testnet chain and it trashed it ...
41 2015-06-10 10:31:56 <phantomcircuit> moa, testnet might very well have reorged too far back
42 2015-06-10 10:32:35 <moa> well i should qualify that with, I might have trashed it
43 2015-06-10 11:00:48 <Luke-Jr> wumpus: I don't know a portable way to improve on BITCOIN_SUBDIR_TO_INCLUDE (particularly, to include comments in-line)
44 2015-06-10 11:01:14 <Luke-Jr> especially within the regex
45 2015-06-10 11:03:19 <Primexor> I wonder how the gradual increase implemention is going
46 2015-06-10 11:03:45 <Primexor> To sustain Bitcoin for 100 years
47 2015-06-10 11:05:37 <Primexor> "The Martian" trailer is out, Bitcoin node on Mars soon
48 2015-06-10 11:06:22 <nkuttler> make sure not to watch the trailer. tells the entire story
49 2015-06-10 11:06:37 <Primexor> Too late
50 2015-06-10 11:25:45 <jonasschnelli> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/6265/files#r32107917, what do you mean with random keys?
51 2015-06-10 11:26:14 <Luke-Jr> jonasschnelli: the current key generation uses random data to make new keys; that should go away
52 2015-06-10 11:26:48 <jonasschnelli> Luke-Jr: ah. Okay. hdsendtoaddress already uses bip32 to generate childkeys in the internal chain
53 2015-06-10 11:27:17 <jonasschnelli> but agreed. It would be better to take sendmany
54 2015-06-10 11:28:02 <jonasschnelli> But however, i think the hdsend* commdands should not be there. Better detect the hd-ness withing the existing send* commands and use it if use have added at least one hd chain of keys.
55 2015-06-10 11:28:08 <Luke-Jr> jonasschnelli: normal sendtoaddress/sendmany should use BIP32 too
56 2015-06-10 11:28:22 <Luke-Jr> right
57 2015-06-10 11:28:46 <Luke-Jr> hdsendmany would make sense if the user wanted to choose a change chain explicitly
58 2015-06-10 11:28:47 <jonasschnelli> Luke-Jr: yes. This is the plan. But a save transition would be, having the commands with the hd* prefix to allow better testing and a smoother transition.
59 2015-06-10 11:29:08 <sipa> you mean getnewaddress?
60 2015-06-10 11:29:18 <sipa> what does send have to do with hd?
61 2015-06-10 11:29:19 <Luke-Jr> sipa: no, change outputs
62 2015-06-10 11:29:24 <sipa> oh, sure
63 2015-06-10 11:29:40 <sipa> ok
64 2015-06-10 11:29:50 <Luke-Jr> jonasschnelli: well, that's part of why -upgradewallet is important too ;)
65 2015-06-10 11:29:59 <jonasschnelli> getnewaddress could also make hd ready. But getNEWaddress (the NEW) somehow implies that something NEW is generated.
66 2015-06-10 11:30:20 <sipa> it is already not new
67 2015-06-10 11:30:28 <sipa> it comes from the keypool
68 2015-06-10 11:30:29 <Luke-Jr> jonasschnelli: the address is "new" in the HD sense too ;)
69 2015-06-10 11:30:38 <jonasschnelli> agreed. :)
70 2015-06-10 11:30:56 <jonasschnelli> But maybe it could make sense to allow to select the desired child index as parameter for hdgetaddress
71 2015-06-10 11:31:08 <jonasschnelli> to avoid the static up-counting
72 2015-06-10 11:32:46 <sipa> overkill imho :)
73 2015-06-10 11:34:14 <jonasschnelli> sipa: what if you like to import a seed with relevant keys in m/44/0/0/0/1000+?
74 2015-06-10 11:34:29 <jonasschnelli> You then need to create (unpack) m/44/0/0/0/0-999 first
75 2015-06-10 11:34:52 <Luke-Jr> jonasschnelli: adding new records, is a change to wallet format.
76 2015-06-10 11:35:13 <Luke-Jr> otoh, maybe in this particular case it's okay provided each new HD address also adds the old records
77 2015-06-10 11:35:18 <jonasschnelli> Luke-Jr: Agreed. But you should be able to run the new wallet format also on a older client.
78 2015-06-10 11:36:08 <Luke-Jr> jonasschnelli: pretty sure BIP32 doesn't require creating 0-999 to get 1000+
79 2015-06-10 11:37:06 <jonasschnelli> Luke-Jr: what if you have a master seed (from a different wallet) where key 1001 was used to receive some coins. You then need the pubkey for 1001 to allow a -reindex to detect your coins.
80 2015-06-10 11:37:29 <jonasschnelli> But the whole wallet restore with master seed needs more brain-work on the concept.
81 2015-06-10 11:38:39 <Luke-Jr> jonasschnelli: restoring from a mere seed is always lossy, no matter what you do
82 2015-06-10 11:38:42 <jonasschnelli> Luke-Jr, sipa: what do you guys think about https://gist.github.com/maaku/8996338 as output format for masterseeds (instead of bip39)
83 2015-06-10 11:39:14 <Luke-Jr> jonasschnelli: you mean instead of BIP 32? :p
84 2015-06-10 11:39:29 <jonasschnelli> nope. 39 (mnemoic brain wallet stuff)
85 2015-06-10 11:39:43 <Luke-Jr> jonasschnelli: my point being that BIP32 also has a format
86 2015-06-10 11:39:59 <jonasschnelli> Luke-Jr: you mean the xpriv...?
87 2015-06-10 11:40:04 <Luke-Jr> yes
88 2015-06-10 11:40:57 <jonasschnelli> but that would be encoding of the master private key. I think encoding the used 32byte seed is more straigh forward and with maakus encoding it would one allow to safely write down on a piece of paper
89 2015-06-10 11:41:52 <Luke-Jr> there is a difference between the master private key and the seed?
90 2015-06-10 11:42:09 <sipa> have you seen https://bitcointalk.org/index.php?topic=102349.0 ?
91 2015-06-10 11:42:11 <jonasschnelli> Luke-Jr: I think only the size.
92 2015-06-10 11:43:06 <sipa> i think it's superior to any proposal i've seen for that (dictionary independent, works against human-provided entropy, scales with technology, has a checksum against typos)
93 2015-06-10 11:44:53 <jonasschnelli> sipa: i have to read that in detail. But what would be wrong if one just keeps the pure bip32 master keey seed to recover after a disaster happened?
94 2015-06-10 11:45:37 <sipa> jonasschnelli: humans don't write down binary, you need some encoding :)
95 2015-06-10 11:46:18 <jonasschnelli> okay. Got your point.
96 2015-06-10 11:47:15 <sipa> now my proposal there is not an encoding, but an algorithm to generate text which is convertible into a seed
97 2015-06-10 11:47:22 <sipa> which is a step further
98 2015-06-10 12:01:35 <jonasschnelli> sipa: okay. So resulting encoded seed could be something like: "peach plaid frogs lapse eight naive toni room ford uvula buick slyly faint ivy horn lurid dwelt award sepia troll jute"?
99 2015-06-10 12:02:57 <sipa> for example
100 2015-06-10 12:03:51 <sipa> bu it's not correct to call it an encoding
101 2015-06-10 12:04:07 <sipa> you can't start from the seed and produce that
102 2015-06-10 12:12:38 <wallet42> proposing new POW: mining docker hostnames root@000006936e69:/# bitcoin-cli
103 2015-06-10 12:13:51 <jonasschnelli> sipa: and what if we would say, 32byte entropy is something that a) needs time to write down on a paper (base32 + error correction + DAMM) or b) needs to be printed (much faster then write down). I somehow don't see the benefit of word-list based encoding of a master seed. Maybe i don't understand that in detail, but if i create a new hd wallet, all what i want is a hard copy (paper) of my master seed (hex).
104 2015-06-10 12:29:43 <jonasschnelli> would it be evil to add a boolean arg (getraw=true) to "sendmany" which then would enforce sendmany to send back the signed transation as hex and the used fee within the json response?
105 2015-06-10 12:30:08 <jonasschnelli> This would allow to check the fee and send if with sendrawtransation
106 2015-06-10 12:31:06 <jonasschnelli> Obviously, as bigger as the time-delta (between sendmany raw and sendrawtx) becomes as higher the chance is, that the required fee has changed.
107 2015-06-10 12:45:35 <sipa> jonasschnelli: now you're just reimplementing create+fund+sign ?
108 2015-06-10 12:46:28 <jonasschnelli> sipa: because fund is not there and create+fund+sign is much more timeconsimung then sendmany i was thinking it is maybe worth adding the hex output. Its more or less a one-liner.
109 2015-06-10 12:49:38 <sipa> jonasschnelli: purpose of the rpc is not using it by hand :)
110 2015-06-10 12:51:24 <jonasschnelli> sipa: yes. But it would be sooo convenient to use sendmany get hex, check fee and broadcast. If you like to check the used fee it need to be a two-steps-rpc-thing (which would required some tx encoding).
111 2015-06-10 13:04:19 <jgarzik> mornin'
112 2015-06-10 13:04:29 <jeremias> afternoon
113 2015-06-10 13:04:36 <gavinandresen> howdy y'all
114 2015-06-10 13:10:05 <jtimon> wumpus around? do you have a better suggestion for the doc in #6061 ?
115 2015-06-10 13:10:41 <jtimon> it's the last non-moveonly thing pending for #6051, yay!
116 2015-06-10 13:27:37 <Shogun__> hi guys
117 2015-06-10 13:27:44 <Shogun__> i have a question
118 2015-06-10 13:27:53 <Shogun__> kinda important one
119 2015-06-10 13:28:42 <Shogun__> im currently running version 0.10.1-precise1 of bitcoind
120 2015-06-10 13:28:57 <Shogun__> and i've come across a bug
121 2015-06-10 13:29:31 <Shogun__> i've got a website making 150 bitcoin transactions each day
122 2015-06-10 13:29:56 <Shogun__> and someone reported a bug today that he received double his money
123 2015-06-10 13:30:30 <Shogun__> so i looked into the problem and it seems the api sometimes lies about failing a transaction
124 2015-06-10 13:31:10 <Shogun__> is someone online?
125 2015-06-10 13:31:17 <Shogun__> willing to help?
126 2015-06-10 13:32:25 <Shogun__> hello?
127 2015-06-10 13:32:27 <Shogun__> someone?
128 2015-06-10 13:36:35 <Primexor> That guy must be an excellent trader
129 2015-06-10 14:43:46 <JackH> can I force more nodes to use my node to download from somehow?
130 2015-06-10 14:43:51 <JackH> I hardly get above 25 ever
131 2015-06-10 14:44:10 <JackH> how can I get my full node to become more "central" as a service point?
132 2015-06-10 14:45:38 <helo> JackH: usage should be discussed in #bitcoin
133 2015-06-10 14:50:32 <sipa> JackH: i don't understand what incentive you could have for that :)
134 2015-06-10 14:52:57 <JackH> sipa none other than because I can ;)
135 2015-06-10 15:52:40 <wumpus> jtimon: just a one-liner about what the function does, it's good now
136 2015-06-10 16:48:27 <maaku> jonasschnelli: base32 is so, so much better than base58. but for most applications you actually want something different entirely
137 2015-06-10 16:49:00 <sipa> agree there
138 2015-06-10 16:49:21 <sipa> base58 was horrible for the purpose it tried to serve, and base32 (or just hex!) are far better
139 2015-06-10 16:49:38 <sipa> but i doubt its purpose is the problem we should be solving
140 2015-06-10 16:49:45 <maaku> right
141 2015-06-10 16:50:39 <maaku> but still, every now and then you need to dump binary data somewhere (URL parameter, nonce, whatever), and for those purposes, base32 or hex
142 2015-06-10 16:51:04 <maaku> although in ideal workflows a human never touches it
143 2015-06-10 17:11:16 <priidu> the only mandatory part of a bip0021 uri is the bitcoin address, right?
144 2015-06-10 19:57:03 <brand0> this might be out of left field, but has anyone tried using a source code verifier/theorem prover on parts of the bitcoin codebase?
145 2015-06-10 20:00:06 <gmaxwell> brand0: sure, well, it's currently more or less infeasable to use in a useful way on bitcoin core itself; in part due to Bitcoin Core being C++. But for libsecp256k1 I've used frama-c to verify some parts of it.
146 2015-06-10 20:00:29 <gmaxwell> I'd like to do more of that in the future as well, but the tools in that space are fairly limited.
147 2015-06-10 20:00:38 <brand0> I was thinking specifically about opcodes
148 2015-06-10 20:00:52 <brand0> but that's interesting about libsecp256k1
149 2015-06-10 20:06:55 <gmaxwell> The more mature direction for building formally provable code is to write it in CoQ and create an extractor to produce runable code in some other language... rather than going around the other way, since trying to prove things about an arbritary language means you have to formalize the semantics of nearly the whole language.
150 2015-06-10 20:07:16 <gmaxwell> For C the language is simple enough that this has been done, but it seems unlikely to ever happen for C++.
151 2015-06-10 20:09:54 <brand0> yeah, that makes sense
152 2015-06-10 20:39:28 <warren> sigh, the sourceforge thing keeps coming up. maybe it's time we actually do something about this.
153 2015-06-10 20:49:59 <bad_duck> sourceforce is becoming a crappy website, I understand that people didn't like story with gimp and other project's hijacks
154 2015-06-10 20:50:58 <warren> bad_duck: other projects? didn't hear about this.
155 2015-06-10 20:52:35 <bad_duck> warren: there was a "sf-editor1" added to the bitcoin project and a lot of other projects
156 2015-06-10 20:52:43 <bad_duck> event if they didn't do anything for the moment
157 2015-06-10 21:53:05 <gmaxwell> bad_duck: the sf-editor1 was added at our request after the account as hacked.
158 2015-06-10 21:53:13 <gmaxwell> thats how we got the account back.
159 2015-06-10 21:56:28 <bad_duck> gmaxwell: didn't know about that (when gavin removed it he didn't know)
160 2015-06-10 21:57:16 <bad_duck> gmaxwell: but they also mess with nmap project -> http://seclists.org/nmap-dev/2015/q2/194
161 2015-06-10 21:58:31 <gmaxwell> bad_duck: yea, we should have removed it right after but that slipped through.
162 2015-06-10 21:58:52 <gmaxwell> Not defending SF or anything, just pointing out that in this case that wasn't a direct sign for concern.
163 2015-06-10 21:59:01 <gmaxwell> We don't use SF for software distribution anymore.
164 2015-06-10 22:01:07 <bad_duck> yes I saw that, it's nice
165 2015-06-10 23:23:04 <null_radix> does any have an example secp256k1 sig that has a recovery id of 2?
166 2015-06-10 23:23:25 <null_radix> actully is that valid?
167 2015-06-10 23:23:33 <sipa> it's extremely unlikely to occur, but it is possible
168 2015-06-10 23:23:41 <sipa> and they can be constructed using key recovery
169 2015-06-10 23:25:53 <null_radix> i need a fixture for testing
170 2015-06-10 23:26:35 <null_radix> ahh gotcha sipa
171 2015-06-10 23:26:36 <null_radix> thanks
172 2015-06-10 23:28:02 <sipa> libsecp256k1 actually has unit tests that do this
173 2015-06-10 23:30:55 <null_radix> im checking it out
174 2015-06-10 23:33:08 <null_radix> great, i think i found it https://github.com/bitcoin/secp256k1/blob/master/src/tests.c#L1723
175 2015-06-10 23:40:11 <warren> bad_duck: I don't like sourceforge's archive browser either.
176 2015-06-10 23:56:50 <bad_duck> warren: same here