1 2014-06-10 00:08:23 <brandondahler> Bitcoin-Qt doesn't require a bitcoin.conf file by default, only bitcoind requires it.
2 2014-06-10 00:09:22 <brandondahler> @grunz: if you create it and set options in it, bitcoin-qt will read them, any further questions need to be taken to #bitcoin or somewhere else
3 2014-06-10 00:38:49 <dgenr8> Dear qt wizards, suppose I'm in WalletModel::updateTransaction. would you have any advice on how to force a switch to the transactions (history) tab? ie navigating all the code-separation thorniness?
4 2014-06-10 00:58:10 <dgenr8> is Diapolo on irc?
5 2014-06-10 01:00:50 <gribble> diapolo was last seen in #bitcoin-dev 1 week, 4 days, 12 hours, 56 minutes, and 3 seconds ago: <Diapolo> wumpus: Any thoughts on what I wrote above?
6 2014-06-10 01:00:50 <justanotheruser> ;;seen diapolo
7 2014-06-10 01:14:32 <SomeoneWeird> https://github.com/blog/1847-locking-conversations
8 2014-06-10 04:41:56 <dabura667> nd address, sends the bitcoins using standard p2kh and it'd be done. I think this would help end address reuse AND the "replace sendto address on client before send" trick that a lot of malware seems to be taking recently. Any thoughts?
9 2014-06-10 04:41:56 <dabura667> What are some of the possible drawbacks to having a name registration type of transaction on the blockchain? I was thinking if a user could register a utxo with their stealth address + a human choosable ascii address, we could decentralize a sort of bitcoin address registrar. This way when a user sends 1 BTC to "johndoe@bitcoin" or whatever, the client looks for the utxo, gets the stealth address, generates the shared secret a
10 2014-06-10 04:42:29 <Luke-Jr> dabura667: that already exists, it's called Namecoin
11 2014-06-10 04:42:40 <Luke-Jr> dabura667: just needs better integration with bitcoin wallet software
12 2014-06-10 04:42:52 <dabura667> Not to mention stealth addresses support p2sh multisig as well.
13 2014-06-10 04:43:44 <dabura667> Luke-Jr: yeah, I looked into their system... but I was thinking that it would be better to have the lookup registrar and the bitcoin sending be under the same mining tree.
14 2014-06-10 04:44:00 <Luke-Jr> dabura667: they are!
15 2014-06-10 04:44:05 <Luke-Jr> dabura667: Bitcoin and Namecoin are mined together
16 2014-06-10 04:44:16 <dabura667> mindblow... how does that work?
17 2014-06-10 04:44:41 <Luke-Jr> dabura667: https://en.bitcoin.it/wiki/Merged_mining_specification has some of the technical details
18 2014-06-10 04:44:59 <Luke-Jr> dabura667: not sure if it covers any of the newer stuff beyond Namecoin's yet
19 2014-06-10 04:45:09 <dabura667> hmmmmm
20 2014-06-10 04:46:06 <dabura667> Interesting... the case for stealth addresses gets stronger... I'll look into it, thanks.
21 2014-06-10 04:46:53 <dabura667> I also propose a new name for Dual-key Stealth Addresses, let's call them "Permanent Addresses"
22 2014-06-10 04:47:21 <gmaxwell> we'd proposed calling them "reusable addresses"
23 2014-06-10 04:47:26 <Luke-Jr> let's not call anything "addresses"? it gives people the wrong idea :P
24 2014-06-10 04:47:56 <Belxjander> Email based Endpoints for Transactions?
25 2014-06-10 04:48:10 <Luke-Jr> Belxjander: they aren't email-based at all
26 2014-06-10 04:49:00 <Belxjander> Recyclable Labels?
27 2014-06-10 04:49:03 <dabura667> I had a dream last night where I typed in "pedronomous@bitcoin" into a wallet and then I Matrix style looked into the phone and it went to the blockchain, looked up pedronomous, found my friend's stealth address, then generated the secret and sent the p2sh of his 2 of 3 stealth, and we were done.
28 2014-06-10 04:49:14 <Belxjander> Luke-Jr: just throwing name ideas at the wall and seeing which ones stick :)
29 2014-06-10 04:49:43 <dabura667> Bitcoin ID?
30 2014-06-10 04:49:52 <dabura667> nah...
31 2014-06-10 04:50:25 <Luke-Jr> actually, I guess the problems with "address" might not be problems for stealth addresses
32 2014-06-10 04:50:32 <Belxjander> Named Transactions?
33 2014-06-10 04:50:39 <dabura667> I wish I knew C... then I'd start coding some stuff for bitcoin... but for now I'll just mess around in python...
34 2014-06-10 04:52:04 <dabura667> a stealth address only needs to be created once. So it's exactly like e-mail addresses except for one BIG factor... it's gibberish to the layman. We need human choosable obfuscations
35 2014-06-10 04:52:59 <Belxjander> so basically any "Labelled CryptoCurrency Wallet" where there is a Human readable name attached to a Wallet Instance?
36 2014-06-10 04:52:59 <Luke-Jr> yeah, sounds like a perfect match for namecoin
37 2014-06-10 04:53:50 <Belxjander> start with raw BitCoin then attach a namecoin?
38 2014-06-10 04:55:24 <dabura667> No. The Namecoin registry costs nothing just to look up.
39 2014-06-10 04:55:41 <dabura667> I think it requires namecoins in order to register though, correct?
40 2014-06-10 05:00:48 <dabura667> I also think that instead of a prefix that you run hashes for to trade anonymity for processing power should have an option to just put in a 4 byte nonce that every sender should use for the nonce in the stealth txout. Also maybe allow inserting the scan privkey just to allow anyone to check their balance if they wished so... It would make the stealth address really long... but if a name registrar was hiding the stealth addres
41 2014-06-10 05:00:48 <dabura667> s, I don't see how it would matter.
42 2014-06-10 05:02:35 <dabura667> no prefix + don't share scan privkey = super anonymous... Set nonce + shared scan privkey in address = super transparency
43 2014-06-10 05:03:21 <dabura667> and all of this is hidden from the user on namecoin and they are shown just "pedronomous@bitcoin" or something like that.
44 2014-06-10 05:04:19 <dabura667> gaaaaah, in the time it would take me to gain the skills to code all this bitcoin will probably already be ocified in hardware chips and unable to be changed...
45 2014-06-10 05:04:28 <Luke-Jr> dabura667: problem is it's too private
46 2014-06-10 05:04:48 <dabura667> Luke-Jr: not if you choose transparency
47 2014-06-10 05:04:49 <Luke-Jr> dabura667: the recipient has no way to know *who* sent him the bitcoins
48 2014-06-10 05:04:55 <Luke-Jr> and the sender has no way to prove it was him
49 2014-06-10 05:05:29 <dabura667> hmmm
50 2014-06-10 05:05:46 <dabura667> you mean signing messages and whatnot, correct?
51 2014-06-10 05:06:00 <Luke-Jr> signing messages only proves you receive with a given address, it doesn't prove you sent anything
52 2014-06-10 05:06:09 <Luke-Jr> nor does it have any applicability to stealth addresses AFAIK
53 2014-06-10 05:06:29 <dsnrk> Luke-Jr: could reveal k to prove you made a transaction :P
54 2014-06-10 05:07:35 <dabura667> your wallet generates all the privkeys for every transaction, so your client could let you pick a transaction in the tx history and sign a message "for this transaction" which in the background will use the privkey of the address used in that tx.
55 2014-06-10 05:08:05 <Luke-Jr> it's possible, sure.
56 2014-06-10 05:08:16 <Luke-Jr> well, for normal transactions.
57 2014-06-10 05:08:19 <dabura667> Also, adding this functionality will not negate the original p2kh starts with 1 addresses.
58 2014-06-10 05:08:25 <Luke-Jr> what if all your coins were received on a stealth address
59 2014-06-10 05:08:27 <Luke-Jr> ?
60 2014-06-10 05:08:48 <Luke-Jr> dabura667: my point is that these new functionalities are *useless* without a solution here
61 2014-06-10 05:08:57 <dabura667> then you own all the keys to those transactions
62 2014-06-10 05:09:01 <Luke-Jr> what good is sending someone money if they don't know you sent it, and you can't prove it?
63 2014-06-10 05:10:01 <dabura667> You can prove it if you choose a transparent stealth address as I explained above.
64 2014-06-10 05:10:26 <dabura667> the receiver would be able to track your stealth address, look it up on namecoin and show "received by "dabura667@bitcoin""
65 2014-06-10 05:11:08 <dabura667> I would use my transparent address for day to day shopping and my anonymous address for large holdings / if I were into silk road etc. that kind of stuff
66 2014-06-10 05:11:45 <dabura667> received from dabura667@bitcoin * sorry my English is bad
67 2014-06-10 05:11:49 <Luke-Jr> dabura667: um, you want privacy for everything, not just shady stuff
68 2014-06-10 05:12:19 <dabura667> What if you're a charity like Seans Outpost?
69 2014-06-10 05:12:41 <dabura667> you can choose transparency but default is anonymity.
70 2014-06-10 05:13:03 <Luke-Jr> then you've made it impossible to use the anonymous ones again
71 2014-06-10 05:13:17 <dabura667> what?
72 2014-06-10 05:14:03 <dabura667> Do you mean "if the option for full transparency is available, no one can ever use the anonymous option ever again?" I am not understanding you.
73 2014-06-10 05:15:25 <dabura667> I could also transmit my bitcoin address "dabura667@bitcoin" encrypted with the generated pubkey of that transaction, and embed it into the transaction, so only the person with the spend privkey for the receiving address can decode who the sender was.
74 2014-06-10 05:15:38 <dabura667> What I'm saying is, there are ways to do this.
75 2014-06-10 05:16:19 <Belxjander> the only way I see of being able to do the public and private split would literally be to split each wallet into having a Public ID and a Private ID
76 2014-06-10 05:16:34 <Belxjander> where anything "anonymous" mandates the private ID seperate from the public ID
77 2014-06-10 05:17:55 <dabura667> Well, like I just said, we could just encrypt the "dabura667@bitcoin" in the tx so that the receiver only can decrypt & see it.
78 2014-06-10 05:18:28 <Belxjander> dabura667: but that in itself is still identifiable once decrypted correct?
79 2014-06-10 05:18:43 <dabura667> but the only person able to decrypt is the receiver
80 2014-06-10 05:19:14 <dabura667> I can copy paste a private encrypted email I receive from someone on pastebin, but that doesn't mean the encryption is useless.
81 2014-06-10 05:19:55 <dabura667> you could then flip a switch that says "ok, now don't include the address in the tx" and the receiver won't know who sent it.
82 2014-06-10 05:20:00 <dabura667> anonymous donations etc.
83 2014-06-10 05:20:21 <dabura667> address = "dabura667@bitcoin"
84 2014-06-10 05:21:27 <dabura667> heck you could even encrypt your scan privkey into the tx and then the sender could not only see your dabura667@bitcoin, but also look up the balance for every transaction received to the sender's stealth ever.
85 2014-06-10 05:21:48 <Belxjander> dabura667: I haven't really been following the conversation all that much
86 2014-06-10 05:22:49 <Belxjander> dabura667: but I get the idea you might need to mind-map how you would want the steps to work and see how far you can explain the idea from that?
87 2014-06-10 05:25:12 <dabura667> Belxjander: yeah, a lot of the stuff I'm talking about also assumes complete knowledge of how the Dual-key Stealth Address protocol works. (The one Dark Wallet is using)
88 2014-06-10 05:25:35 <dabura667> scan keypair as compared to spend keypairs etc.
89 2014-06-10 05:25:38 <Belxjander> dabura667: not that far into things like that myself
90 2014-06-10 05:26:34 <dabura667> hmmm... I'll see if I have time to write up something that's at least understandable to devs familiar with the basic protocol workings...
91 2014-06-10 05:28:18 <dabura667> I dunno if I could ever ELI5 it for normal people though...
92 2014-06-10 05:33:07 <netg_> 7&
93 2014-06-10 05:33:09 <netg_> 6
94 2014-06-10 06:03:09 <CoinHeavy> is the âsizeâ field returned by `bitcoind getinfo` the size of the current block in bytes?
95 2014-06-10 06:04:18 <CoinHeavy> I looked through the wiki and the dev docs but I wasnât able to find an answer; the help text for `bitcoind help getinfo` just says âsize : n (numeric) the block sizeâ
96 2014-06-10 06:05:46 <wumpus> it's the size of the block in bytes
97 2014-06-10 06:07:17 <wumpus> dgenr8: you could raise a signal, the GUI could subscribe to this and switch tabs, but I think switching tabs on response to an asynchronous event is a user-disrespecting idea
98 2014-06-10 06:08:16 <Luke-Jr> erm
99 2014-06-10 06:08:21 <Luke-Jr> getinfo doesn't return a "size" field at all
100 2014-06-10 06:08:49 <maaku> CoinHeavy: do you mean getutxosetinfo?
101 2014-06-10 06:08:51 <wumpus> Luke-Jr: suppose he means getblock
102 2014-06-10 06:10:49 <CoinHeavy> sorry, my bad â I meant getblock
103 2014-06-10 06:11:06 <CoinHeavy> thanks for the clarification
104 2014-06-10 06:11:41 <sipa> yes, size in bytes in that case
105 2014-06-10 07:18:11 <gmaxwell> wumpus: perhaps there is some risk that someone added one of those and hasn't yet sent funds to it... but otherwise, I think it's likely that I'm the only doofus who added a 30 of 30 to his wallet as a test. :)
106 2014-06-10 07:18:39 <sipa> well, clearly not
107 2014-06-10 07:19:00 <sipa> elichai2- seems to have a 10-uncompressed-pubkey multisig
108 2014-06-10 07:19:52 <gmaxwell> How'd he get that?!
109 2014-06-10 07:20:40 <sipa> there was some site involved, no clue whether they generated the address or no
110 2014-06-10 07:20:57 <gmaxwell> :-/
111 2014-06-10 07:21:42 <gmaxwell> maybe addmultisigaddress should be rejecting uncompressed anyways.
112 2014-06-10 07:22:10 <wumpus> gmaxwell: so to be clear: the sanity check was added because redeemscripts longer than that cannot actually be used, and anyone sending funds to them would lose them?
113 2014-06-10 07:22:18 <gmaxwell> Right.
114 2014-06-10 07:22:46 <sipa> the redeemscript must be < 520 bytes
115 2014-06-10 07:22:47 <gmaxwell> (I'd explicitly added that script to see if we'd allow it⦠thats how my wallet ended up in that state. :) )
116 2014-06-10 07:24:22 <wumpus> it may be that CBasicKeyStore::AddCScript is the wrong place to add that check in the first place
117 2014-06-10 07:25:24 <wumpus> the wallet loading cannot distinguish errors, so if AddCScript fails that may be because the input is wrong, but also because the database messed up or some completely unrelated reason
118 2014-06-10 07:25:35 <gmaxwell> dunno, it certantly shouldn't be actually loading such a key. E.g. we should be able to assume the invariant that there are no such things loaded.
119 2014-06-10 07:25:48 <wumpus> ignoring errors from AddCSCript thus sounds potentially dangerous
120 2014-06-10 07:25:54 <gmaxwell> if not for the fact that we used to allow this we'd probably want to treat it as wallet corruption.
121 2014-06-10 07:26:23 <wumpus> we can of course replicate the specific check in the wallet loading, and do it before calling AddCScript
122 2014-06-10 07:26:26 <gmaxwell> yea, we really only want to ignore _that_ error. (this, incidentally, is why I didn't fix it right when petertodd added the check... I've been patching it out)
123 2014-06-10 07:27:11 <gmaxwell> we want to make sure to reject them elsewhere, not just on load.
124 2014-06-10 07:27:21 <wumpus> even though it duplicates some code that seems to be the cleanest way to just ignore that error, not others
125 2014-06-10 07:28:11 <wumpus> that's what I mean -- so keep the error in AddCScript, but check specifically for the >520 condition in CWallet::LoadCScript before calling that and ignore it if so
126 2014-06-10 07:28:39 <gmaxwell> yea, makes sense.
127 2014-06-10 07:28:49 <gmaxwell> I didn't think of that. :)
128 2014-06-10 07:29:48 <wumpus> we ought to have used status codes instead of true/false booleans for error return values, but heh, this will work
129 2014-06-10 07:56:02 <wumpus> gmaxwell: can you try https://github.com/bitcoin/bitcoin/pull/4316?
130 2014-06-10 07:59:19 <wumpus> again: can anyone gitian-build 0.9.2rc2, I'm still the only builder, this is holding the release back
131 2014-06-10 08:00:14 <Luke-Jr> wumpus: ok
132 2014-06-10 08:00:36 <Luke-Jr> might take a while, I don't know if I have the deps build
133 2014-06-10 08:00:47 <wumpus> ok no problem
134 2014-06-10 08:00:58 <Luke-Jr> sorry, I thought we had lots of gitian builders these days XD
135 2014-06-10 08:01:35 <wumpus> we do have quite a lot, but everyone seems to be above building a lowly rc :)
136 2014-06-10 08:02:01 <Luke-Jr> âº
137 2014-06-10 08:02:27 <sipa> "I only build N.0.0 releases!"
138 2014-06-10 08:03:01 <sipa> i'll try to get gitian going again when i find some time
139 2014-06-10 08:03:48 <Luke-Jr> grumble, I hate gitian's lack of package management
140 2014-06-10 08:03:55 <Luke-Jr> doesn't even download files for you :p
141 2014-06-10 08:05:13 <Luke-Jr> wtf, we're using a newer miniupnpc than Gentoo even has unstable? :|
142 2014-06-10 08:05:35 <sipa> "gentoo is just slow, it's the new debian"
143 2014-06-10 08:05:37 <sipa> ACTION ducks
144 2014-06-10 08:06:02 <Luke-Jr> sipa: sometimes it really is
145 2014-06-10 08:06:12 <Luke-Jr> we're actually stuck on Bitcoin Core 0.8
146 2014-06-10 08:06:32 <Luke-Jr> (well, the overlay has 0.9.1 ofc)
147 2014-06-10 08:07:27 <wumpus> Luke-Jr: yes IIRC there was some security issue that forced the upgrade
148 2014-06-10 08:07:44 <Luke-Jr> :x
149 2014-06-10 08:07:58 <wumpus> so gentoo may be wise to upgrade it as well
150 2014-06-10 08:08:51 <Luke-Jr> ah, looks like they finally got on it this week https://bugs.gentoo.org/show_bug.cgi?id=512666
151 2014-06-10 08:09:37 <wumpus> Luke-Jr: feel free to add package management to gitian :)
152 2014-06-10 08:10:07 <wumpus> I think there should at least be a way to: put inputs into other directories, as well as make it save the outputs to other directories
153 2014-06-10 08:10:13 <gmaxwell> wumpus: 2014-06-10 08:09:54 LoadCScript: Warning: This wallet contains a redeemScript of size 927 which exceeds maximum size 520 thus can never be redeemed
154 2014-06-10 08:10:15 <Luke-Jr> wumpus: I've taken a few stabs at adding determinism to Gentoo instead.
155 2014-06-10 08:10:18 <gmaxwell> works fine.
156 2014-06-10 08:10:36 <Luke-Jr> wumpus: seems much more likely to be a productive direction IMO
157 2014-06-10 08:10:40 <wumpus> this would allow for better dependency tracking, and means not having a copy after the build step that you can forget
158 2014-06-10 08:11:01 <gmaxwell> wumpus: might be nice if it gave the address too. "don't use this one"
159 2014-06-10 08:11:05 <Luke-Jr> problem is GCC/LLVM code is a mess
160 2014-06-10 08:11:23 <wumpus> everyone always complains about gitian but it's a simple bag of ruby and shell scripts, making a change really isn't that daunting :p
161 2014-06-10 08:11:28 <wumpus> gmaxwell: good idea
162 2014-06-10 08:11:50 <Luke-Jr> wumpus: gitian, sure. Portage is simple too. but the best way to do this is to have GCC always produce deterministic output for the same input ;)
163 2014-06-10 08:12:15 <Luke-Jr> wumpus: so I want a flag that tells it to get the random seed from the preprocessed source code
164 2014-06-10 08:12:47 <Luke-Jr> I hacked up distcc to do it, and it worked decently, but GCC command line flags are insane to parse outside GCC, so it was never quite perfect
165 2014-06-10 08:13:28 <Luke-Jr> (distcc works only because it can fall back to "just run GCC natively")
166 2014-06-10 08:15:30 <Luke-Jr> oh good, I don't have to rebuild boost/qt
167 2014-06-10 08:17:32 <wumpus> gmaxwell: can you retest, it should display the address now
168 2014-06-10 08:20:07 <gmaxwell> sure
169 2014-06-10 08:24:19 <gmaxwell> hah
170 2014-06-10 08:24:20 <gmaxwell> 8:23:11 LoadCScript: Warning: This wallet contains a redeemScript of size 927 which exceeds maximum size 520 thus can never be redeemed. Do not use address (unknown).
171 2014-06-10 08:24:53 <gmaxwell> I suppose ExtractDestination is failing on the same test.
172 2014-06-10 08:29:48 <wumpus> gmaxwell: or maybe we should use ExtractDestinations and not ExtractDestination
173 2014-06-10 08:30:13 <wumpus> hm... no
174 2014-06-10 08:30:28 <wumpus> this is a p2sh redeemscript, it should be hashed and *then* converted to an address
175 2014-06-10 08:30:43 <wumpus> ExtractDestination is not the right way
176 2014-06-10 08:31:39 <wumpus> CBitcoinAddress(script.GetID()).ToString() that should do it
177 2014-06-10 08:31:48 <gmaxwell> wumpus: CBitcoinAddress(script.GetID())
178 2014-06-10 08:31:54 <gmaxwell> hah. yea...
179 2014-06-10 08:34:28 <wumpus> gmaxwell: ok... repushed
180 2014-06-10 08:36:16 <gmaxwell> wumpus: yea I already tested it before commenting above. It works now.
181 2014-06-10 08:36:25 <wumpus> ok :)
182 2014-06-10 08:54:15 <gdm85> wumpus: I can gitian-build 0.9.2rc2, hopefully new dependencies won't bring in new issues
183 2014-06-10 08:54:48 <wumpus> gdm85: the only dependency that has changed is openssl, it shouldn't bring any more issues than it already does...
184 2014-06-10 08:55:05 <gdm85> wumpus: from 0.9.1? I saw cdr or am I mistaken?
185 2014-06-10 08:55:23 <wumpus> no, from 0.9.2rc1
186 2014-06-10 08:55:38 <wumpus> 0.9.2 added the macosx gitian buld, so that naturallly pulls in some more inputs
187 2014-06-10 08:56:05 <gdm85> I am afraid I won't be cross-building for Mac OS X nor Windows for now
188 2014-06-10 08:59:46 <gdm85> the asterisk syntax for IP addresses is still supported, but deprecated, correct?
189 2014-06-10 09:20:56 <Luke-Jr> wumpus: pushed win sigs; but there's a mismatch on src
190 2014-06-10 09:21:17 <Luke-Jr> I don't think I'll be able to stay up for the rest tonight