1 2012-03-26 02:02:51 <luke-jr> https://github.com/luke-jr/bitcoin/compare/customfee <-- any comments?
  2 2012-03-26 02:56:58 <BlueMatt> luke-jr: NACK for the same reason all the similar stuff has been nack'd for the past year or more
  3 2012-03-26 02:57:37 <BlueMatt> (I even wrote the same patch a long time ago for wx-gui, when I still didnt really understand bitcoin all the way...)
  4 2012-03-26 03:02:12 <luke-jr> BlueMatt: I haven't seen any similar stuff, and presumably neither have the people offering the bounty
  5 2012-03-26 03:18:18 <BlueMatt> luke-jr well then their google-fu sucks
  6 2012-03-26 03:18:38 <luke-jr> so why NACK?
  7 2012-03-26 03:18:45 <BlueMatt> (And are idiots thinking that just changing the minfee does anything)
  8 2012-03-26 03:18:54 <luke-jr> &
  9 2012-03-26 03:19:23 <BlueMatt> I didnt...
 10 2012-03-26 03:19:40 <luke-jr> it's the miner side.
 11 2012-03-26 03:20:00 <BlueMatt> Ah, well then that is interesting
 12 2012-03-26 03:20:40 <BlueMatt> But just setting minfee is also a nack
 13 2012-03-26 03:20:56 <luke-jr> &
 14 2012-03-26 03:21:06 <BlueMatt> And just as strong of one
 15 2012-03-26 03:21:55 <luke-jr> thankfully, not all devs are so insistent on forced centralization :p
 16 2012-03-26 03:22:01 <BlueMatt> That isnt how txfees are "supposed" to be done
 17 2012-03-26 03:22:09 <BlueMatt> Noooo
 18 2012-03-26 03:22:22 <BlueMatt> I dont think the current minfee rules are good
 19 2012-03-26 03:22:27 <BlueMatt> Quite the opposite
 20 2012-03-26 03:22:55 <BlueMatt> The reason i hate it when people write fee patches (like that one) without thinking
 21 2012-03-26 03:23:05 <BlueMatt> Is because you arent thinking...
 22 2012-03-26 03:23:32 <BlueMatt> The fee system needs redone in some way that is sane
 23 2012-03-26 03:23:53 <BlueMatt> NOT blindly accepting a different minfee or minfeeper setting
 24 2012-03-26 03:24:25 <BlueMatt> That is rediculous and just highly encourages miners to pursue the downward fee spiral
 25 2012-03-26 03:26:06 <luke-jr> upward*
 26 2012-03-26 03:26:15 <BlueMatt> Hah wat?
 27 2012-03-26 03:26:26 <BlueMatt> What are you smoking?
 28 2012-03-26 03:26:53 <luke-jr> the implementation requested only supports upward fee changes
 29 2012-03-26 03:27:20 <luke-jr> max(vanilla-rules, custom-rules)
 30 2012-03-26 03:27:36 <BlueMatt> Mmm, well i suppose that isnt as objectionable
 31 2012-03-26 03:27:55 <BlueMatt> Though the miners who requested it are kinda dumb...
 32 2012-03-26 03:29:01 <BlueMatt> s/kinda/really/
 33 2012-03-26 03:31:05 <BlueMatt> Link to the bount?
 34 2012-03-26 03:31:09 <BlueMatt> Y
 35 2012-03-26 03:31:51 <luke-jr> https://bitcointalk.org/index.php?topic=73941.0
 36 2012-03-26 03:33:29 <BlueMatt> Wait, luke-jr does eligius take txfees as pool fee or are they distributed?
 37 2012-03-26 03:33:50 <luke-jr> BlueMatt: they're basically ignored right now
 38 2012-03-26 03:34:00 <BlueMatt> ???
 39 2012-03-26 03:34:07 <BlueMatt> You mean dropped?
 40 2012-03-26 03:34:09 <luke-jr> I need to rework the code before that 25 BTC drop
 41 2012-03-26 03:34:30 <BlueMatt> You always generate 50 and drop fees?
 42 2012-03-26 03:34:33 <luke-jr> no, the fee processor uses them for payouts still
 43 2012-03-26 03:34:47 <luke-jr> but the whole reward calculation just assumes 50 BTC flat
 44 2012-03-26 03:35:13 <luke-jr> s/fee processor/payout processor/
 45 2012-03-26 03:35:24 <BlueMatt> so...they go to you?
 46 2012-03-26 03:35:41 <BlueMatt> or what, in some cases they are lost? Im confused...
 47 2012-03-26 03:36:10 <luke-jr> they go somewhere eventually, when I bother to account for them
 48 2012-03-26 03:36:28 <luke-jr> srsly not worth the effort right now
 49 2012-03-26 03:36:34 <BlueMatt> oh, so they are in a holding account?
 50 2012-03-26 03:36:51 <luke-jr> they're not destroyed.
 51 2012-03-26 03:37:03 <BlueMatt> so they just sit in a holding account to be paid out eventually?
 52 2012-03-26 03:37:18 <luke-jr> there's not really a 1:1 link between mined blocks and payouts
 53 2012-03-26 03:37:28 <BlueMatt> yea
 54 2012-03-26 03:37:52 <BlueMatt> I thought you had a holding account to hold coins over from one block to the next depending on...I dont remember what
 55 2012-03-26 03:38:23 <BlueMatt> hmm, interesting idea, as long as 50btc makes up a >> % of eligius payouts than the txes, forcing the pool to not include low-fee txes doesnt really hurt individual miners (much) but increases minfee...
 56 2012-03-26 03:38:26 <BlueMatt> interesting idea...
 57 2012-03-26 03:38:43 <BlueMatt> that guy kinda solved the downward fee spiral issue...
 58 2012-03-26 03:38:56 <BlueMatt> well until we get to low payouts
 59 2012-03-26 03:39:04 <BlueMatt> which is when the fee issue actually matters anyway...
 60 2012-03-26 03:39:11 <BlueMatt> but interesting idea nonetheless
 61 2012-03-26 03:39:17 <luke-jr> BlueMatt: there's an overflow address when the payout code doesn't have enough to pay immediately, but I often mix it into my offline storage until needed
 62 2012-03-26 03:41:17 <luke-jr> someday I'll need to search the blockchain for total Eligius txn fees and deal with it :P
 63 2012-03-26 03:41:30 <luke-jr> but no rush since the info's always there
 64 2012-03-26 03:45:40 <BlueMatt> luke-jr: fair enough I suppose
 65 2012-03-26 03:51:36 <BlueMatt> anyway, Im off; still wondering why that guy wants to exclude more fee-holding txes, but whatever...
 66 2012-03-26 03:52:40 <luke-jr> presumably to provide incentive for more people to pay optionally higher fees for faster processing
 67 2012-03-26 03:53:18 <luke-jr> possibly in hopes of staggering the 25 BTC subsidy crash
 68 2012-03-26 05:26:03 <gribble> New news from bitcoinrss: Diapolo opened pull request 988 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/988>
 69 2012-03-26 12:40:08 <gribble> New news from bitcoinrss: luke-jr opened pull request 989 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/989>
 70 2012-03-26 12:55:19 <gribble> New news from bitcoinrss: sipa opened pull request 990 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/990>
 71 2012-03-26 12:58:28 <bluemoon23> has anyone had any sucess mining btc
 72 2012-03-26 12:58:37 <sipa> see #bitcoin-mining
 73 2012-03-26 13:07:18 <gavinandresen> sipa:  I'm going through the issues list this morning, marking any remaining 0.6.0 issues with the 0.6.0 milestone
 74 2012-03-26 13:15:03 <luke-jr> sipa: gpg: [stdin]: encryption failed: Unusable public key
 75 2012-03-26 13:15:17 <sipa> luke-jr: ?
 76 2012-03-26 13:15:29 <luke-jr> sipa: GPG doesn't like your pubkey :P
 77 2012-03-26 13:15:36 <luke-jr> trying to encrypt my testnet dir to you
 78 2012-03-26 13:15:43 <sipa> 1DAAC974 ?
 79 2012-03-26 13:16:16 <luke-jr> yeah
 80 2012-03-26 13:16:22 <SomeoneWeird> lol
 81 2012-03-26 13:16:25 <luke-jr> aha
 82 2012-03-26 13:16:28 <luke-jr> I didn't have your subkey
 83 2012-03-26 13:16:32 <luke-jr> let's try again
 84 2012-03-26 13:16:54 <luke-jr> there we go
 85 2012-03-26 13:25:48 <BlueMatt> gavinandresen wait, you want to disable uris in win32 for 0.6????
 86 2012-03-26 13:25:57 <gavinandresen> yes
 87 2012-03-26 13:26:28 <BlueMatt> The issues are fixed...
 88 2012-03-26 13:27:09 <gavinandresen> I don't like the fixes-- patching boost, complicated looking code that retries stuff.....
 89 2012-03-26 13:27:15 <BlueMatt> Plus we need an exorberent amount of time in rc5 thanks to all the changes anyway...
 90 2012-03-26 13:27:41 <gavinandresen> So lets add Even More Stuff that might go wrong???
 91 2012-03-26 13:28:19 <sipa> First of all, let's add more punctuation!!!
 92 2012-03-26 13:28:31 <BlueMatt> Its a dead simple patch to boost to fix a documented
 93 2012-03-26 13:28:40 <BlueMatt> Bug
 94 2012-03-26 13:29:00 <BlueMatt> Also my irc client is freezing every two seconds...have to talk later
 95 2012-03-26 13:29:37 <gavinandresen> ok.  I'm working on a couple of patches now, one that fixes the installer so it removes the old bitcoin.exe
 96 2012-03-26 13:30:00 <gavinandresen> And another that will disable URI handling in the source and in the setup.nsi
 97 2012-03-26 13:32:02 <sipa> I think we need an rc5 quickly; rc4 has a bug (my fault) that makes it fail some reorganizations, and p2pool are required to upgrade to a BIP16-enabled bitcoind soon.
 98 2012-03-26 13:32:29 <luke-jr> gavinandresen: maybe a good compromise would be to disable URI handling in 0.6.0, with the understanding that we backport the fix to 0.6.1 when it's in master?
 99 2012-03-26 13:32:42 <luke-jr> ie, re-enable it when fixed
100 2012-03-26 13:32:59 <luke-jr> sipa: there's 0.5.4rc1 for p2pool too
101 2012-03-26 13:33:21 <sipa> right
102 2012-03-26 13:34:01 <gavinandresen> yes, we need rc5 today
103 2012-03-26 13:34:07 <sipa> luke-jr: did you backport minimize impact of large reorgs?
104 2012-03-26 13:34:44 <luke-jr> sipa: not yet
105 2012-03-26 13:35:09 <luke-jr> sipa: it didn't seem urgent, and possibly bug-prone
106 2012-03-26 13:35:30 <sipa> it turned out to be so, indeed
107 2012-03-26 13:36:01 <luke-jr> ETA 2 mins on my testnet upload encrypted to Gavin and Sipa
108 2012-03-26 13:36:11 <luke-jr> it's about 42 MB
109 2012-03-26 13:51:30 <luke-jr> gavinandresen: sipa: http://luke.dashjr.org/tmp/code/testnet.tbz2.pgp
110 2012-03-26 13:52:03 <gavinandresen> luke-jr: what is that?
111 2012-03-26 13:53:01 <gavinandresen> or, more specifically, why are you giving me the contents of your testnet directory?
112 2012-03-26 13:53:25 <luke-jr> gavinandresen: to reproduce the addr.dat lockup
113 2012-03-26 13:53:43 <gavinandresen> ah, ok, great.
114 2012-03-26 13:55:45 <luke-jr> oops. hope I didn't break your dl
115 2012-03-26 14:04:08 <sipa> luke-jr: got it
116 2012-03-26 14:04:55 <gavinandresen> somebody remind me how to tell qt to build a -g Makefile?
117 2012-03-26 14:05:04 <luke-jr> qmake CONFIG+=debug
118 2012-03-26 14:05:20 <gavinandresen> thanks (was doing config+=DEBUG ....)
119 2012-03-26 14:10:55 <luke-jr> sipa: gavinandresen: either of you can confirm the whole dir reproduces it for you?
120 2012-03-26 14:11:05 <sipa> it reproduces the problem indeed, here
121 2012-03-26 14:11:24 <luke-jr> k
122 2012-03-26 14:12:19 <gavinandresen> luke-jr: I downloaded it, but am busy testing a disable-uri-handling-on-windows patch
123 2012-03-26 14:12:53 <luke-jr> well, it works for sipa. I just wanted to be sure there wasn't some oddball external factor involved
124 2012-03-26 14:14:05 <sipa> it's quite a problem, if a single thread can cause a deadlock :S
125 2012-03-26 14:14:27 <gavinandresen> I think there's a bdb setting to debug deadlock issues
126 2012-03-26 14:27:12 <gribble> New news from bitcoinrss: gavinandresen opened pull request 991 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/991>
127 2012-03-26 14:47:37 <gribble> New news from bitcoinrss: gavinandresen opened pull request 992 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/992>
128 2012-03-26 14:57:48 <gribble> New news from bitcoinrss: gavinandresen opened issue 993 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/993>
129 2012-03-26 15:11:33 <BlueMatt> gavinandresen: https://github.com/bitcoin/bitcoin/pull/991#issuecomment-4698782
130 2012-03-26 15:13:12 <BlueMatt> gavinandresen: doing config += DEBUG slows down bitcoin-qt due to the linking of qt debug libraries
131 2012-03-26 15:13:34 <BlueMatt> gavinandresen: best way: CXXFLAGS += -g and if you are on win32, add a LDFLAGS -= -Wl,-s
132 2012-03-26 15:15:20 <sipa> i really don't understand #982
133 2012-03-26 15:15:46 <sipa> i've managed to make the entire database environnement to shut down between loading the file, and rewriting it
134 2012-03-26 15:15:56 <sipa> but now it blocks on reopening the database env
135 2012-03-26 15:16:09 <gavinandresen> BlueMatt: thanks (although I don't really care if bitcoin-qt is slower....)
136 2012-03-26 15:16:15 <sipa> oh no, it segfaulted
137 2012-03-26 15:16:35 <BlueMatt> gavinandresen: well it killed me...(that was the reason I thought CBlockStore had really odd performance issues for months...)
138 2012-03-26 15:24:33 <sipa> i give up
139 2012-03-26 15:25:09 <sipa> close the entire db env before rewriting the file, and still, when it tries to write its first non-ignored entry, it deadlocks
140 2012-03-26 15:25:19 <sipa> valgrind sees no problem at all
141 2012-03-26 15:28:11 <sipa> i don't understand how bdb can correctly call pthread_cond_wait if there is only a single thread alive
142 2012-03-26 15:28:22 <sipa> that's a guaranteed deadlock
143 2012-03-26 15:29:57 <luke-jr> :/
144 2012-03-26 15:30:18 <BlueMatt> yay, lets rewrite bdb too ;)
145 2012-03-26 15:30:56 <gmaxwell> By rewrite you mean ... avoid using, right?
146 2012-03-26 15:31:21 <BlueMatt> well, that too
147 2012-03-26 15:32:08 <sipa> actually, addrman just serializes its entire database (it's guaranteed to be max 1.5 MiB) and dumps it into a single bdb entry
148 2012-03-26 15:32:21 <sipa> you don't actually need bdb there anymore
149 2012-03-26 15:32:36 <BlueMatt> hah, nice
150 2012-03-26 15:33:00 <sipa> though i preferred to keep it, since it gives recovery in case of crash; otherwise you'd need to deal with partial overwrites and such
151 2012-03-26 15:36:03 <sipa> i really don't know what to do here anymore: just not overwrite addr.dat at all, and leave all old addr entries there?
152 2012-03-26 15:36:25 <sipa> or maybe again try to get bdb to actually delete all those entries
153 2012-03-26 15:36:38 <BlueMatt> does bdb get mad trying to delete that many entries?
154 2012-03-26 15:37:19 <sipa> then again: if rewriting has this potential effect, it could have the same problem for wallet.dat
155 2012-03-26 15:38:08 <BlueMatt> odd that we've never (I think?) seen it though...
156 2012-03-26 15:41:44 <BlueMatt> sipa: is christiansen a common danish name?
157 2012-03-26 15:42:07 <BlueMatt> or do you know many danish people?
158 2012-03-26 15:42:53 <sipa> i know one danish person, and his name is christiansen
159 2012-03-26 15:43:04 <sipa> oh no, christian andersen
160 2012-03-26 15:43:13 <BlueMatt> well, nevermind then...
161 2012-03-26 15:43:18 <sipa> why?
162 2012-03-26 15:43:27 <BlueMatt> kinda random, someone was saying it was a common danish name
163 2012-03-26 15:43:36 <BlueMatt> I thought Id ask someone who was geographicaly closer...
164 2012-03-26 15:44:06 <sipa> well, the -sen is like -son in English, it means "son of", and Christian is certainly a danish name
165 2012-03-26 15:44:31 <BlueMatt> well, thanks
166 2012-03-26 15:45:08 <lyspooner> tribeca, eh gavinandresen?
167 2012-03-26 15:47:22 <gavinandresen> lyspooner: yup.  Sounded like it'll be fun.    (is there a link up to the event somewhere?)
168 2012-03-26 15:47:39 <lyspooner> http://www.indiewire.com/article/susan-sarandon-shepard-fairey-rob-lowe-will-participate-in-2012-tribeca-talks
169 2012-03-26 15:48:55 <gavinandresen> cool, I'll get to meet Ally Sheedy!
170 2012-03-26 15:49:19 <BlueMatt> ooo, youre going to tribeca?
171 2012-03-26 15:49:43 <gavinandresen> yup.  They're showing War Games and then having a panel discussion
172 2012-03-26 15:49:48 <BlueMatt> heh, nice
173 2012-03-26 15:50:15 <Joric> 1983 War Games?
174 2012-03-26 15:50:27 <lyspooner> Hello Joshua
175 2012-03-26 15:50:58 <gmaxwell> the SMBC remix of the ending was pretty funny.
176 2012-03-26 15:51:00 <Joric> i love password joshua5
177 2012-03-26 15:51:21 <gmaxwell> http://www.youtube.com/watch?v=TFCOapq3uYY
178 2012-03-26 15:51:27 <lyspooner> "the only way to win is to have 51% of hashing power"?
179 2012-03-26 16:18:00 <sipa> luke-jr: my deladdr branch should fix your issue
180 2012-03-26 16:21:13 <sipa> luke-jr: actually no, it doesn't compile
181 2012-03-26 16:23:04 <sipa> there, better
182 2012-03-26 16:27:32 <diki> you know
183 2012-03-26 16:27:39 <diki> the PCRE library is so fun to compile
184 2012-03-26 16:27:56 <diki> because it neednt anything special to make it compile
185 2012-03-26 16:28:05 <diki> it works right out of the box with no third party libs required
186 2012-03-26 16:28:17 <diki> compiles PERFECTLY on windows, even has static and shared libs
187 2012-03-26 16:28:31 <diki> and one can succesfully statically link without a hiccup
188 2012-03-26 16:28:40 <sipa> wonderful
189 2012-03-26 16:29:43 <gribble> New news from bitcoinrss: sipa opened pull request 994 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/994>
190 2012-03-26 16:47:06 <gavinandresen> away for an hour or so; when I'm back (or before if sipa/gmaxwell feel like pulling) I think the rc5 plan should be pull 991/992/994, tag and build (unless I'm forgetting any showstopper issues)
191 2012-03-26 16:50:44 <BlueMatt> sipa/gmaxwell care to comment on #991?
192 2012-03-26 17:09:00 <gmaxwell> BlueMatt: "bleh"
193 2012-03-26 17:09:44 <gmaxwell> I agree the feature is at least mildly important, but I didn't like the boost::interprocess stuff to begin with either.
194 2012-03-26 17:10:05 <wumpus> what's so bad about the boost::interprocess stuff really?
195 2012-03-26 17:10:23 <wumpus> I agree we shouldn't be fixing boost issues but...
196 2012-03-26 17:10:50 <wumpus> it's not exactly the only workaround we have for upstream problems
197 2012-03-26 17:10:56 <gmaxwell> wumpus: nothing is 'so' bad about it. But e.g. the fact that we had to test to figure out what would happen with multiple copies running was kind of bleh.
198 2012-03-26 17:11:26 <gmaxwell> It's just more mystery meat code and buggy mystery meat apparently.
199 2012-03-26 17:12:18 <wumpus> that's true
200 2012-03-26 17:12:48 <gmaxwell> It'll also be buggy mystery meat exposed to hostile input.
201 2012-03-26 17:13:19 <gmaxwell> So bleh. I do think the answer is to fix not remove, but 0.6 is about to become an urgent release.
202 2012-03-26 17:13:20 <rebroad> I notice that in some recent changes some boost foreachs changed into non-boost ones.. is there some move away from boost happening...?
203 2012-03-26 17:13:59 <sipa> rebroad: where exactly?
204 2012-03-26 17:14:01 <wumpus> it's too bad qt doesn't have a same-machine ipc mechanism (it has qt network but that's not really what we want)
205 2012-03-26 17:14:23 <gmaxwell> So, luke's suggestion of of slipping it a release to 0.6.1 didn't sound horrible to me. But I really shouldn't comment too much as I'm likely to undervalue the feature as its not something I'd use.
206 2012-03-26 17:14:29 <wumpus> and qtdbus but that's a linux-only party....
207 2012-03-26 17:14:44 <rebroad> oh.... what's urgent in 0.6, please gmaxwell? (or is there a webpage I can go to that will answer that question...?)
208 2012-03-26 17:15:11 <sipa> rebroad: the BIP16 changeover data is april first, and there is no stable release that implements it yet
209 2012-03-26 17:15:16 <rebroad> sipa: ummm. I forget now... I thought perhaps it was in some of your recent patches
210 2012-03-26 17:16:25 <sipa> also, 0.5.0 is alreadt 4 months old
211 2012-03-26 17:16:27 <rebroad> my client is still gaining height very slowly.... maybe 4 blocks per minute.. disk IO and CPU are both low...
212 2012-03-26 17:16:39 <wumpus> we should release 0.6.0 asap, imo
213 2012-03-26 17:17:17 <Joric> is that compressed keys thing really well thought? e.g. payment to a secret key may be ambiguous
214 2012-03-26 17:17:17 <sipa> wumpus: the problem is that the longer we wait to incorporate more changes, the more time we need to let the rc's be tested
215 2012-03-26 17:18:09 <sipa> Joric: you mean import a private key? yes, the serialization of that private key will indicate whether the corresponding address is derived from the compressed or non-compressed pubkey
216 2012-03-26 17:18:10 <wumpus> yes
217 2012-03-26 17:18:25 <rebroad> sipa, what's the impact of clients taking ages to switch to BIP16? how quickly do clients update when there's a message stating urgent update?
218 2012-03-26 17:18:30 <helo> with p2sh multisig, can different key sign different parts of the transaction? so one key may control/lock the destination address, and another the amount?
219 2012-03-26 17:18:53 <rebroad> is BIP16 ever "urgent" really? I mean, it's been lived without for so long...
220 2012-03-26 17:19:06 <sipa> rebroad: it's urgent for solo miners and p2pool users
221 2012-03-26 17:19:09 <sipa> not for users
222 2012-03-26 17:19:33 <sipa> helo: not really, there is some control over what is signed (see the SIGHASH_x types)
223 2012-03-26 17:19:51 <sipa> +though
224 2012-03-26 17:20:35 <sipa> Joric: it's really not that hard: there will be two base58 serialized private keys, and each will correspond to exactly one base58 address
225 2012-03-26 17:20:42 <Joric> sipa, i can import those, i'm just a bit scared by the ambiguity of the old good 32-bit secret )
226 2012-03-26 17:20:50 <rebroad> I was thinking of a potential nice feature..... a directory linking bitcoin addresses to email addresses.
227 2012-03-26 17:21:22 <sipa> Joric: the fact that the internal 32-byte secret for both is the same, is not visible
228 2012-03-26 17:21:43 <Joric> those addresses are, in fact, linked
229 2012-03-26 17:21:56 <sipa> yes, you should not use both
230 2012-03-26 17:21:58 <rebroad> sipa, ah, so the BIP16 change won't be an alert for bitcoin-qt...?
231 2012-03-26 17:22:02 <sipa> rebroad: no
232 2012-03-26 17:22:23 <wumpus> rebroad: yes, has been discussed on the mailing list many times, look for "aliases"... the problem is implementing it in a secure way, without being dependent on a single organization that makes the mapping
233 2012-03-26 17:27:25 <rebroad> wumpus, well, there could be a number of directories run by different people/organisations, and the client could gossip about those different directories either over the p2p protocol, or amongst a separate p2p protocol (if deemed not core functionality)
234 2012-03-26 17:28:08 <rebroad> people would choose which directories they register with (if any)
235 2012-03-26 17:29:19 <sipa> if those are centralized directories, there is no need to do it over p2p
236 2012-03-26 17:29:45 <sipa> and using static addresses is a bad idea for bitcoin's general privacy model
237 2012-03-26 17:30:17 <wumpus> yesanother practical issue
238 2012-03-26 17:30:28 <gmaxwell> It's not only bad for the privacy of the user with the static address it's bad for the people they interact with, and even the people they interact with.
239 2012-03-26 17:30:47 <rebroad> sipa, well the list of directories could be gossiped about in the same way that ed2k servers are gossiped about amongst ed2k servers and kamilla (or whatever the p2p leg is called)
240 2012-03-26 17:30:47 <sipa> gmaxwell: yes, if it were only bad for people themselves, i wouldn't mind too much
241 2012-03-26 17:31:12 <gavinandresen> pullilng....
242 2012-03-26 17:31:21 <wumpus> also using the same static address means that you have no way to identify the sender / transaction specifically
243 2012-03-26 17:31:23 <rebroad> sipa, people who want privacy won't be registering addresses...
244 2012-03-26 17:31:41 <sipa> rebroad: that's not the problem
245 2012-03-26 17:31:45 <rebroad> people who want anonymity can just choose not to use them, and addresses that use them
246 2012-03-26 17:31:48 <wumpus> it's a very easy feature to think of but tricky to implement well, we've seen a lot of talk about it but zero implementations
247 2012-03-26 17:32:24 <gmaxwell> rebroad: please reread my prior message, I was anticipating your response and already replied to it.
248 2012-03-26 17:32:28 <sipa> rebroad: even if you care about anonimity, and i don't, me using static addresses and doing transactions with you will negatively impact your privacy
249 2012-03-26 17:32:30 <wumpus> if you want it merged in the mainline client you need to address that
250 2012-03-26 17:32:38 <rebroad> wumpus, the list of addresses doesn't need to be any more static than the use of addresses..
251 2012-03-26 17:33:09 <wumpus> you can't just waive privacy away because you don't think it's important
252 2012-03-26 17:33:36 <sipa> bitcoin's entire privacy model depends on people not reusing addresses (too much)
253 2012-03-26 17:33:56 <sipa> (not only on that, though)
254 2012-03-26 17:34:16 <rebroad> gmaxwell, I think I read it and responded didn't i?
255 2012-03-26 17:34:54 <rebroad> wumpus, only people who want to waive privacy will be waiving it.. and only for the addresses they chose to waive it for
256 2012-03-26 17:35:10 <sipa> rebroad: now read everything we said the last 20 lines again
257 2012-03-26 17:35:21 <rebroad> sipa, we're not talknig about privacy here
258 2012-03-26 17:35:42 <sipa> i'm not sure you understand
259 2012-03-26 17:35:47 <rebroad> privacy will continue to be an option for anyone who wants it
260 2012-03-26 17:35:54 <wumpus> rebroad, to prevent falling into repetition I suggest you read prior discussions on the mailing list
261 2012-03-26 17:36:11 <rebroad> people can have as many private addresses as they like, and as many non-private as they like
262 2012-03-26 17:36:19 <wumpus> there have been many smart people thinking about this already
263 2012-03-26 17:36:35 <sipa> rebroad: your privacy depends on not doing transactions with people who are not careful with their privacy
264 2012-03-26 17:36:43 <sipa> and that is something you cannot control
265 2012-03-26 17:37:06 <sipa> so no, something that encourages giving up privacy is not only bad for those who chose it, but for the entire network
266 2012-03-26 17:37:08 <rebroad> wumpus, I can do... how would I find them please?
267 2012-03-26 17:37:16 <gmaxwell> Not recieving funds from them, not sending funds to them or more generally, not letting them know who you are.
268 2012-03-26 17:37:46 <rebroad> sipa, I realise that... and this would in fact help people to avoid doing that also
269 2012-03-26 17:38:16 <sipa> maybe, but there has not been any consensus about this yet, and many people have thought about it
270 2012-03-26 17:38:44 <wumpus> any way, I think the best argument for not re-using addresses is to be able to label transcations and reconcile them with other places, for example so that you know which package to mail... static addresses linked to mails would *only* work for donations
271 2012-03-26 17:39:01 <sipa> exactly
272 2012-03-26 17:39:14 <sipa> for e-commerce you need a more complex setup anyway
273 2012-03-26 17:39:22 <rebroad> sipa, my suggestion will help with privacy as much as non-privacy...  so people can achieve either better
274 2012-03-26 17:40:06 <sipa> rebroad: then write it out and implement it and convince people that it's safe, but i'm not sure you're aware of all issues around it
275 2012-03-26 17:40:16 <wumpus> even for simple person-to-person commerce you'd need a more complex setup
276 2012-03-26 17:40:25 <rebroad> well, I was thinking, I could set up a website that allows people to register an email to a bitcoin address (or are there already any/many around?), and then try to establish a standard protocol for querying it.. and then finally allow the bitcoin client to gossip about these directories
277 2012-03-26 17:40:49 <rebroad> wumpus, only if it was a 1 to 1 relationship
278 2012-03-26 17:41:18 <sipa> rebroad: ok, i create a fake service that says "rebroad's address is 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa"
279 2012-03-26 17:41:30 <sipa> (which is my donation address)
280 2012-03-26 17:41:36 <wumpus> also make it *secure*... that's the hard part
281 2012-03-26 17:41:43 <rebroad> admittedly the directory would get rather big if people registered thousands of bitcoin addresses per email address...
282 2012-03-26 17:41:47 <sipa> how do i know which service to trust?
283 2012-03-26 17:42:00 <Joric> did anyone try to squeeze ecdsa 256k into a visible range? i wonder how it looks like
284 2012-03-26 17:42:27 <sipa> the only thing i can imagine is if the services have an own namespace
285 2012-03-26 17:42:28 <wumpus> maybe it could work with gpg keyservers somehow
286 2012-03-26 17:42:38 <sipa> like the part after @ in email addresses
287 2012-03-26 17:42:43 <Joric> jcryptool won't visualize sec256k - "Large elliptic curves are used in professional cryptography. Because of the size of the curves, it's not possible to display a grid or the points of the curve"
288 2012-03-26 17:43:07 <wumpus> if you have signed the address with your gpg key (verified in the usualy web-of-trust way) that should be pretty safe...