1 2014-01-21 00:00:10 <alex_fun> http://www.reddit.com/r/Bitcoin/comments/1qqmr4/ghashiocexio_and_doublespending_against_betcoin/
2 2014-01-21 00:00:25 <alex_fun> is it true cex.io double spent its bets in casino?
3 2014-01-21 00:00:34 <alex_fun> and how can such thing work?
4 2014-01-21 00:01:31 <maaku> alex_fun: yes, the responsible parties have been sacked, and the people who sacked have been sacked, and #bitcoin
5 2014-01-21 00:02:04 <alex_fun> maaku but that means they do it again and again?
6 2014-01-21 00:02:16 <alex_fun> is there some improvement to fix it?
7 2014-01-21 00:02:29 <alex_fun> as now info how to do it is public
8 2014-01-21 00:02:30 <jakov> alex_fun the security assumptions that bitcoin relies on are not valid
9 2014-01-21 00:02:34 <jakov> havent been valid for a while now
10 2014-01-21 00:02:43 <jakov> the assumption about decentralised mining power
11 2014-01-21 00:02:48 <alex_fun> jakov can you expand?
12 2014-01-21 00:03:03 <jakov> bitcoin stops doublespending by assuming most miners are honest
13 2014-01-21 00:03:07 <alex_fun> yes
14 2014-01-21 00:03:12 <alex_fun> that I understand
15 2014-01-21 00:03:14 <jakov> ghash is a large mining pool and was dishonest in that case
16 2014-01-21 00:03:18 <alex_fun> yes
17 2014-01-21 00:03:19 <jakov> so they could doublespend
18 2014-01-21 00:03:32 <alex_fun> but why they did just small double spent against casino
19 2014-01-21 00:03:32 <lianj> jakov: but you could just wait 6 confirmationsâ¦
20 2014-01-21 00:03:36 <lianj> or more
21 2014-01-21 00:03:40 <alex_fun> as they rep is tarnished
22 2014-01-21 00:03:48 <alex_fun> would they not go for max in this case?
23 2014-01-21 00:04:06 <jakov> alex_fun its gets harder the more confirmations you wait
24 2014-01-21 00:04:11 <jakov> the gambling sites use 0 confirms
25 2014-01-21 00:04:16 <alex_fun> hehe how silly
26 2014-01-21 00:04:21 <alex_fun> 0 confirms
27 2014-01-21 00:04:25 <alex_fun> but
28 2014-01-21 00:04:25 <jakov> so if ghash has 40% mining power they can doublespend 40% of the time
29 2014-01-21 00:04:32 <lianj> so its not bitcoins fault
30 2014-01-21 00:04:34 <alex_fun> it has big implication
31 2014-01-21 00:04:38 <jakov> this is all in the original satoshi paper
32 2014-01-21 00:04:52 <alex_fun> as before people was saying that ecommerce should rely on 0 conf
33 2014-01-21 00:04:53 <alex_fun> ;)
34 2014-01-21 00:05:11 <alex_fun> say that btc is not slower than rest when 0 conf is used
35 2014-01-21 00:05:11 <jakov> okay but consider how much it costs to get 40% of mining power
36 2014-01-21 00:05:29 <jakov> just to doublespend for a $5 coffee
37 2014-01-21 00:05:31 <alex_fun> jakov: some just collide when diff is high they gain more via colliding
38 2014-01-21 00:05:38 <jakov> if you're buying anything bigger you wait for more confirms
39 2014-01-21 00:05:48 <alex_fun> jakov: true
40 2014-01-21 00:06:03 <jakov> i saw some of the drug marketplaces wait for 7 confirms
41 2014-01-21 00:06:15 <alex_fun> no wonder as they are smart :D
42 2014-01-21 00:06:22 <jakov> like they took satoshi's conservative 6 confirm estimate and decided even thats not good enough
43 2014-01-21 00:06:29 <jakov> hehe
44 2014-01-21 00:06:53 <jakov> also i guess by the time the drugs get shipped many more confirms will happen
45 2014-01-21 00:07:04 <alex_fun> jakov: some people claim double spent can be done even with 25% of total hash?
46 2014-01-21 00:07:05 <jakov> bitstamp on the other hand use 3 confirms, presumably they compromised to help high frequency arbitrators
47 2014-01-21 00:07:27 <jakov> alex_fun its possible to doublespend with any amount of total hash
48 2014-01-21 00:07:46 <alex_fun> is there is simple math formula to calculate chance of double spend with variables been A=hash% B=confirms?
49 2014-01-21 00:07:47 <jakov> you can doublespend a 0 confirm tx 1% of the time if you have 1% hash power
50 2014-01-21 00:07:50 <jakov> yeah
51 2014-01-21 00:07:51 <jakov> sec
52 2014-01-21 00:07:54 <alex_fun> ty
53 2014-01-21 00:07:55 <jakov> theres a website
54 2014-01-21 00:08:08 <jakov> its not simple, involves some summations, but the javascript does it all
55 2014-01-21 00:08:12 <alex_fun> cool
56 2014-01-21 00:08:41 <jakov> cant seem to find it
57 2014-01-21 00:09:17 <alex_fun> hmm well if u know entire formula I can ask in #math :D
58 2014-01-21 00:09:36 <jakov> its in the satoshi paper
59 2014-01-21 00:09:53 <alex_fun> but satoshi paper is pdf I cant copy paste from it
60 2014-01-21 00:09:56 <alex_fun> LOl
61 2014-01-21 00:10:03 <alex_fun> ok I try something
62 2014-01-21 00:10:45 <alex_fun> is it formula on page 7?
63 2014-01-21 00:11:02 <jakov> i forgot, he writes some c code for it
64 2014-01-21 00:11:12 <jakov> dont bother trying to use the math there
65 2014-01-21 00:11:17 <alex_fun> why
66 2014-01-21 00:11:40 <alex_fun> its better to understand the math
67 2014-01-21 00:11:47 <alex_fun> then its sure thing
68 2014-01-21 00:12:15 <alex_fun> jakov: you can doublespend a 0 confirm tx 1% of the time if you have 1% hash power - then dices would be so bust
69 2014-01-21 00:12:20 <alex_fun> if they use 0 confirm
70 2014-01-21 00:12:25 <alex_fun> lol
71 2014-01-21 00:12:38 <jakov> found it alex_fun https://people.xiph.org/~greg/attack_success.html
72 2014-01-21 00:12:54 <alex_fun> ty
73 2014-01-21 00:12:57 <jakov> alex_fun yeah but you actually have to make a profit
74 2014-01-21 00:13:08 <jakov> so the 99% of the times you dont doublespend you lose money mostly
75 2014-01-21 00:13:10 <jakov> on average
76 2014-01-21 00:13:33 <alex_fun> jakov: `you can doublespend a 0 confirm tx 1% of the time if you have 1% hash power` so say when I use 6 confirms what are the chances of double spend then
77 2014-01-21 00:13:42 <jakov> put it into the website
78 2014-01-21 00:13:50 <alex_fun> jakov: most dices are 3.5% house advantage
79 2014-01-21 00:13:57 <alex_fun> so even 4% hash works then
80 2014-01-21 00:13:59 <jakov> 6 confirms can be reversed 50% of the time with 40% hash power
81 2014-01-21 00:15:39 <alex_fun> jakov what I mean 0 confirm 1% hash 1% chance - when its 6 confirms is it 1/6 % chance?
82 2014-01-21 00:15:50 <jakov> no
83 2014-01-21 00:16:07 <jakov> it drops exponentially
84 2014-01-21 00:16:12 <jakov> its something like 1e-10
85 2014-01-21 00:16:37 <alex_fun> it drops by how much each confirm?
86 2014-01-21 00:16:59 <jakov> i dont know you can easily work it out from that website
87 2014-01-21 00:17:03 <alex_fun> oki
88 2014-01-21 00:17:32 <alex_fun> AttackerSuccessProbability(1,0)=1
89 2014-01-21 00:17:32 <alex_fun> AttackerSuccessProbability(1,6)=1
90 2014-01-21 00:17:34 <alex_fun> hmm
91 2014-01-21 00:17:54 <petertodd> You don't even need to hack GHash.IO to pull off a double-spend like that you know, just use the fact that not all pools are willing to even accept the same tx's into thier mempools.
92 2014-01-21 00:18:22 <jakov> alex_fun you've put in 100% hash power
93 2014-01-21 00:18:23 <petertodd> e.g. Eligius and some others won't accept payments to the batteryhorse address after that dust spam thing.
94 2014-01-21 00:18:28 <jakov> 1% hash power is 0.01
95 2014-01-21 00:18:47 <alex_fun> hey petertodd did u made video called I know who is satoshi? :D
96 2014-01-21 00:19:14 <petertodd> alex_fun: why would I call attention to my secret identity?
97 2014-01-21 00:19:21 <alex_fun> hehhee
98 2014-01-21 00:19:28 <alex_fun> lol
99 2014-01-21 00:19:39 <alex_fun> jakov ok recalculating npw
100 2014-01-21 00:19:41 <alex_fun> now
101 2014-01-21 00:20:01 <alex_fun> AttackerSuccessProbability(0.001,6)=2.51288e-16
102 2014-01-21 00:20:04 <alex_fun> what is e?
103 2014-01-21 00:20:28 <alex_fun> some really small number? like 0.00000000000000000000000000 something?
104 2014-01-21 00:20:43 <jakov> yes thats scientific notation
105 2014-01-21 00:21:12 <alex_fun> but what does it mean?
106 2014-01-21 00:21:16 <shesek> petertodd, did you see what I wrote above about what people started doing with Bitrated's brand? this is really terrible :\
107 2014-01-21 00:21:19 <shesek> https://bitcointalk.org/index.php?topic=423843.0
108 2014-01-21 00:22:11 <petertodd> shesek: +1 on DKIM and SPF, but yeah, not much you can do to stop such scams
109 2014-01-21 00:22:33 <jakov> alex_fun thats the probability of a successful doublespend
110 2014-01-21 00:23:38 <shesek> I didn't see that one coming... abusing Bitrated to help them scam
111 2014-01-21 00:24:03 <shesek> I don't understand how anyone could trust an email like that without going over Bitrated and seeing how it should work
112 2014-01-21 00:24:08 <alex_fun> jakov oki
113 2014-01-21 00:24:20 <shesek> reading the FAQ or trying the interface should clearly show them that its not how it works
114 2014-01-21 00:24:41 <alex_fun> AttackerSuccessProbability(0.001,0)=1
115 2014-01-21 00:24:51 <alex_fun> 100% jakov
116 2014-01-21 00:25:42 <jcorgan> did the guy actually send the BTC?
117 2014-01-21 00:26:02 <jakov> sadly yes
118 2014-01-21 00:26:21 <jakov> he says its the third time hes been scammed
119 2014-01-21 00:26:40 <jakov> i dont want to blame the victim but he should maybe start being much more careful
120 2014-01-21 00:26:55 <shesek> about $6500, I feel really bad for that guy
121 2014-01-21 00:27:07 <alex_fun> jakov AttackerSuccessProbability(0.001,0)=1
122 2014-01-21 00:27:18 <alex_fun> means 1% can double spend 0 confirms all the time
123 2014-01-21 00:27:50 <jcorgan> blame is not a scalar; the scammer is to be blamed for his actions (scamming), and person scammed is to be blamed for his actions (serial poor judgement)
124 2014-01-21 00:28:15 <jakov> i know i feel bad for him too
125 2014-01-21 00:28:25 <jakov> is blame a tensor then?
126 2014-01-21 00:29:25 <jcorgan> i do feel bad for the guy, though--hopefully the pain of getting scammed is enough to make him more paranoid
127 2014-01-21 00:29:27 <jakov> i dont think the person being scammed has any blame, they should just be more careful, like when police warn you to not leave valuables in plain view they're not blaming you for getting them stolen
128 2014-01-21 00:29:44 <jakov> jcorgan he says its his third scam, though hopefully not as large
129 2014-01-21 00:30:00 <jakov> i mean, hopefully much larger
130 2014-01-21 00:30:10 <jakov> hopefully the other two scams were for $1 or something
131 2014-01-21 00:31:10 <shesek> btw, I was also notified today by someone else about the very same scam, though he didn't fall for it
132 2014-01-21 00:31:17 <alex_fun> AttackerSuccessProbability(0.3,6)=0.132111
133 2014-01-21 00:31:19 <alex_fun> works nice
134 2014-01-21 00:31:22 <alex_fun> ty jakov
135 2014-01-21 00:33:34 <jcorgan> unfortunately, scamming still pays off. every now and then i take a random read in my email spam folder and think, "who would possibly fall for that?", yet enough must, or they wouldn't do it
136 2014-01-21 00:34:51 <jakov> does anyone know the algorithm for choosing the articles posted in #bitcoin-news ?
137 2014-01-21 00:45:09 <funky> :P
138 2014-01-21 00:51:15 <rdymac> what is Mike Hearn's user here?
139 2014-01-21 00:55:03 <SomeoneWeird> rdymac, TD
140 2014-01-21 01:20:30 <berndj> jcorgan, (1) sometimes paranoia makes people *more* vulnerable to scams, like when they say "i'll be real careful next time and only deal with solid, reputable people". guess who has a huge incentive to learn how to come across as solid and reputable? scammers
141 2014-01-21 01:21:33 <berndj> jcorgan, (2) it isn't just stupid people falling for email scams; it's also those 1 in a million people whose circumstances just happen to align with what the scam email presupposes
142 2014-01-21 01:22:07 <berndj> there's that 1-in-10000 guy who happens to have just send a video to his other mailbox, who gets an "alert: mailbox full" email 5 minutes later
143 2014-01-21 01:22:48 <berndj> ohcrap, sorry for chatterboxing the wrong #
144 2014-01-21 02:43:41 <funky> I am looking at PUBKEY_ADDRESS and base58 but base 58 to text converter does not convert it properly to text
145 2014-01-21 02:59:37 <lechuga__> base58 is text
146 2014-01-21 03:00:22 <funky> well true it can only use 0 to 9 then its text
147 2014-01-21 03:01:20 <lechuga__> how do you come to realize there is a problem
148 2014-01-21 03:02:37 <funky> so SetData(Params().Base58Prefix(CChainParams::PUBKEY_ADDRESS), &id, 20);
149 2014-01-21 03:02:53 <funky> means btc used base59 20?
150 2014-01-21 03:02:57 <funky> uses
151 2014-01-21 03:04:46 <funky> Bitcoin uses its own representation format, known as base58check.
152 2014-01-21 03:09:27 <funky> lechuga__: I wonder how wallet makes letter
153 2014-01-21 03:09:45 <funky> from base58check
154 2014-01-21 03:09:57 <funky> aka how 20 in base58check becomes letter :D
155 2014-01-21 05:47:31 <swulf--> is it typical convention to call "the block at height 1" == the genesis block?
156 2014-01-21 05:48:14 <swulf--> or... a blockchain of height 1 consists only of the genesis block .. ?
157 2014-01-21 05:49:31 <brisque> the genesis block is sort of block zero. it's not counted by the client at any rate.
158 2014-01-21 05:50:33 <swulf--> right, block 0.. but if you're talking about height or depth, is genesis still considered height=0 ?
159 2014-01-21 05:52:20 <brisque> I can't imagine there'd be any reason for it to be considered any other way.
160 2014-01-21 05:52:48 <swulf--> that's what I figured, too. just wanted to be sure :)
161 2014-01-21 05:53:49 <brisque> perhaps somebody else can back me up on that.
162 2014-01-21 05:57:25 <abrkn> swulf: i've been thinking about creating a cryptocurrency-lib, taking code from vbuterin/brainwallet/yours and organizing it better. any reason i should not? the vbuterin-code can do a lot, but the dependency graph is crazy. everything depends on everything
163 2014-01-21 05:57:57 <swulf--> abrkn: cryptocurrency-lib would be a collection of javascript utilities?
164 2014-01-21 05:58:39 <abrkn> swulf: yes. i want small modules that have unit tests
165 2014-01-21 05:58:47 <swulf--> i have no objection to something like that
166 2014-01-21 05:58:50 <swulf--> sounds useful
167 2014-01-21 05:58:51 <abrkn> swulf: to use in the browser, it should be easy to use browserify
168 2014-01-21 05:59:03 <swulf--> I think a great goal would be to make sure 100% of it works offline
169 2014-01-21 05:59:27 <brisque> please, whatever you do, replace the bloody mouse movement RNG everybody is set on using.
170 2014-01-21 05:59:42 <swulf--> don't forget to include ms-brainwallet.org too :)
171 2014-01-21 06:00:13 <abrkn> swulf: after using vbuterin/bitcoinjs-lib for a few weeks now i've determined that it cannot be used in production. one small typo somewhere and you might end up issuing deposit addresses to which you do not have the primary key (encoding errors), etc
172 2014-01-21 06:00:43 <swulf--> well, lots of people ARE using it (brainwallet.org ...)
173 2014-01-21 06:01:07 <brisque> swulf--: yeah, and it's a piece of software written by a known malicious actor. you should *not* trust it.
174 2014-01-21 06:01:17 <swulf--> :-O
175 2014-01-21 06:02:07 <abrkn> swulf: here's my go at bip32 https://github.com/justcoin/bitcoinjs-lib/blob/bip32/src/hdwallet.js
176 2014-01-21 06:02:09 <brisque> swulf--: the author was on here a week or so back asking for help speeding up his cracking of brainwallets. modifying the DNS to serve bad software some visitors is not out of the question.
177 2014-01-21 06:02:19 <abrkn> swulf: and tests https://github.com/justcoin/bitcoinjs-lib/blob/bip32/test/hdwallet.js
178 2014-01-21 06:02:28 <swulf--> that's insane
179 2014-01-21 06:02:32 <swulf--> abrkn: checking now
180 2014-01-21 06:03:24 <brisque> swulf--: just a bit, especially when so many people think it's known good.
181 2014-01-21 06:03:54 <swulf--> abrkn: your code looks nice and clean :)
182 2014-01-21 06:04:00 <abrkn> i think all the ".toHex", ".toBase58", etc should be removed. just keep "toBytes" and the library user can convert himself. would reduce code by -a lot-
183 2014-01-21 06:04:11 <swulf--> brisque: fwiw, it has been used by a lot of people for a long time with no published incidents
184 2014-01-21 06:04:28 <swulf--> abrkn: seems reasonable. your code, your decision on that one:)
185 2014-01-21 06:05:12 <brisque> swulf--: past performance is not indicative of future. it is in at least a little bit malicious, it pre fills the destination address in the transaction view to be the authors own. there's no notification about that, so people keep "donating" funds to it.
186 2014-01-21 06:05:24 <brisque> swulf--: and come on, the author is cracking the keys people create with it.
187 2014-01-21 06:05:30 <swulf--> sure
188 2014-01-21 06:05:32 <brisque> ;;balance 15ArtCgi3wmpQAAfYx4riaFmo4prJA4VsK
189 2014-01-21 06:05:37 <gribble> Error: invalid syntax (<string>, line 1)
190 2014-01-21 06:05:51 <brisque> eh?
191 2014-01-21 06:05:55 <swulf--> brisque: my ms-brainwallet site prefills the destination with some charity's donation address :(
192 2014-01-21 06:06:06 <brisque> swulf--: why not just leave it empty?
193 2014-01-21 06:06:20 <abrkn> swulf: the number of times i've almost sent my money to the pre-filled. should be blank
194 2014-01-21 06:06:20 <swulf--> didn't cross my mind
195 2014-01-21 06:06:25 <swulf--> guess I could do that
196 2014-01-21 06:06:28 <brisque> people have sent.. 185BTC accidentally to the prefilled address.
197 2014-01-21 06:06:33 <swulf--> wow
198 2014-01-21 06:06:48 <brisque> plus whatever the guy has made in cracked brainwallets.
199 2014-01-21 06:06:49 <abrkn> yes, it's very annoying
200 2014-01-21 06:07:28 <brisque> it's malicious, negligent at best.
201 2014-01-21 06:07:57 <swulf--> damn, sorry. gotta run
202 2014-01-21 06:08:11 <swulf--> brisque: yeah, I agree. I'll update the code to leave the dest blank later today
203 2014-01-21 06:08:18 <brisque> swulf--: much appreciated.
204 2014-01-21 06:49:06 <jcorgan> is it documented anywhere how a BIP becomes a law? I'm sure it is rather differnt from Schoolhouse Rock.
205 2014-01-21 06:52:53 <Luke-Jr> jcorgan: there is no law
206 2014-01-21 06:53:22 <Diablo-D3> jcorgan: basically, you start by paying a bunch of congressmen a lot of money under the table
207 2014-01-21 06:53:39 <Diablo-D3> then the BIP is thrown out and replaced with industry-friendly wording
208 2014-01-21 06:53:50 <Diablo-D3> after that, the American people are fucked in the ass without lube.
209 2014-01-21 06:55:30 <SomeoneWeird> facepalm
210 2014-01-21 06:55:38 <jcorgan> lol. i'm just wondering about the fates of bip32, bip38, and bip39
211 2014-01-21 06:58:04 <Diablo-D3> SomeoneWeird: what? he asked dumb answer and got snark in return
212 2014-01-21 06:59:28 <jcorgan> um, to clarify my poor attempt at humor--how does a BIP go from "draft" to "accepted"?
213 2014-01-21 07:00:00 <Diablo-D3> jcorgan: the code for it is committed.
214 2014-01-21 07:00:03 <jcorgan> (I guess I should expect you youngins to get references to 70s culture)
215 2014-01-21 07:00:09 <jcorgan> shouldn't
216 2014-01-21 07:00:15 <Diablo-D3> dude, I know what the fuck you were referring to
217 2014-01-21 07:00:19 <Diablo-D3> everyone does
218 2014-01-21 07:00:22 <Luke-Jr> jcorgan: people use it
219 2014-01-21 07:01:37 <SomeoneWeird> youngins? >_>
220 2014-01-21 07:02:09 <jcorgan> lol, sometimes i do feel like the grampa crashing the party
221 2014-01-21 07:02:47 <SomeoneWeird> idk, most people are way older than me heh
222 2014-01-21 07:03:55 <jcorgan> i met bluematt and felt positively ancient
223 2014-01-21 07:04:00 <Diablo-D3> jcorgan: Im 30!
224 2014-01-21 07:04:24 <SomeoneWeird> how old are you/bluematt?
225 2014-01-21 07:04:42 <jcorgan> I'm 46
226 2014-01-21 07:04:47 <SomeoneWeird> oh, wow
227 2014-01-21 07:19:41 <abrkn> how does bitpay eliminate currency risk? do they actually cover any change in btc/usd for the 15 min?
228 2014-01-21 07:54:20 <happening> Hi I'm trying to implement multisignature transactions, specifically signing and creating the input-script for redemption. For a 2 out of 2 transaction with transaction-input, do I place the redeem-script at the transaction-input-script, serialize transaction, hash, and sign hash with each private key?
229 2014-01-21 07:55:33 <gmaxwell> shesek: Evidence that your service is a success: https://bitcointalk.org/index.php?topic=423843.msg4613678#msg4613678
230 2014-01-21 08:18:18 <brisque> gmaxwell: oh that's terrible.
231 2014-01-21 08:23:18 <gmaxwell> derp, I see shesek replied there right away.
232 2014-01-21 08:24:13 <brisque> impressive that somebody came up with that so quickly though.
233 2014-01-21 08:35:34 <Krellan> gmaxwell: I tried to donate to you but it was before I disabled the mintxfee/minrelaytxfee settings and my TX got stuck
234 2014-01-21 08:36:11 <Krellan> just saw it when I opened the qt client for the first time in a while, and there it was, sticking to the top of the list
235 2014-01-21 08:41:05 <gmaxwell> Krellan: you could try exporting the raw transaction and handing it directly to eligius: http://eligius.st/~wizkid057/newstats/pushtxn.php
236 2014-01-21 08:41:23 <warren> wumpus: nice, gitian win64, I'll test it immediately
237 2014-01-21 08:42:48 <warren> wumpus: the gitian .yml files are still named *win32.yml, not a big deal
238 2014-01-21 08:45:50 <Krellan> gmaxwell: thanks, tried that first
239 2014-01-21 08:46:34 <Krellan> don't get your hopes up, it was only pennies, not sure how that transaction got in there in the first place actually - it was from a few weeks ago
240 2014-01-21 08:51:35 <Krellan> I need to figure out pywallet - having trouble with it on gentoo because it wants bsddb that gentoo no longer has
241 2014-01-21 08:52:21 <brisque> be careful with pywallet.
242 2014-01-21 08:52:38 <brisque> it's not the best for your privacy, shooting off requests to blockchain.info for every address you own
243 2014-01-21 08:57:49 <Krellan> hmm ok thanks for warning
244 2014-01-21 08:58:18 <Krellan> Is there a better way to delete an unwanted TX that was made wrong (insufficient TX fee) and thus stuck at 0/unconfirmed forever?
245 2014-01-21 08:59:34 <Krellan> gmaxwell: I too would love it if bitcoind would have a "minwallettxfee" that I could set higher than "minrelaytxfee" to be sure to generate my own transactions with good fee but still be willing to accept others with less
246 2014-01-21 09:00:05 <Krellan> otherwise we'll never have any wiggle room with which to lower the TX fee over time, as bitcoin continues to rise in value.
247 2014-01-21 09:01:02 <Krellan> the "mintxfee" is for mining only, right, not wallet? maybe call it "minminingtxfee"
248 2014-01-21 09:01:18 <CodeShark> unfortunately, in bitcoin, the only fees are for miners
249 2014-01-21 09:01:27 <CodeShark> it's one of the more broken things about bitcoin :p
250 2014-01-21 09:02:07 <CodeShark> in an ideal world, the relay node could collect the fee for verifying and relaying transactions to miners
251 2014-01-21 09:02:27 <Apocalyptic> CodeShark, bad idea
252 2014-01-21 09:02:48 <CodeShark> in an ideal world - much care would have to be taken in an actual implementation
253 2014-01-21 09:02:51 <Apocalyptic> that would add incentive to disrupt some routes between nodes
254 2014-01-21 09:03:07 <CodeShark> yes, the ideal implementation would take all that into account
255 2014-01-21 09:03:14 <CodeShark> the ideal protocol, that is
256 2014-01-21 09:04:05 <CodeShark> the ideal protocol would reward nodes that provide the most direct, most efficient route to getting a transaction included in a block without rewarding nodes for just moving the data around aimlessly or duplicately
257 2014-01-21 09:04:46 <brisque> I doubt that would be possible in the network as we know it though
258 2014-01-21 09:04:58 <brisque> and does it matter? transactions are instant for all intents.
259 2014-01-21 09:05:26 <CodeShark> it does matter - the more direct and efficient the route, the less of a burden it is on the network as a whole
260 2014-01-21 09:05:56 <wumpus> warren: good point, going to rename them to just win
261 2014-01-21 09:06:22 <brisque> every node needs to have the transaction data though, there's always going to be an inventory request for every single transaction. the amount of data being transferred would be the same no matter what.
262 2014-01-21 09:06:33 <CodeShark> bitcoin as it exists requires the transaction to be flooded - but that needn't be necessarily the case
263 2014-01-21 09:06:48 <CodeShark> but perhaps this convo belongs in wizards :)
264 2014-01-21 09:07:04 <brisque> CodeShark: it does, sorry.
265 2014-01-21 09:07:06 <Apocalyptic> "but that needn't be necessarily the case" for some decentralized 0-trust shceme afaik it is
266 2014-01-21 09:07:06 <warren> wumpus: full of win
267 2014-01-21 09:07:28 <CodeShark> no, the nodes could query for the transaction when the block is published
268 2014-01-21 09:07:48 <CodeShark> and the sender could send the transaction directly to the recipient, the recipient to miners
269 2014-01-21 09:08:03 <theorbtwo> Not just decentralized, semi-anonymous.
270 2014-01-21 09:08:29 <CodeShark> you could hide your IP address if that's your concern
271 2014-01-21 09:08:36 <theorbtwo> CodeShark: How does the sender send directly to the recipient if the sender doesn't necceessarly know where the recipient is?
272 2014-01-21 09:08:51 <oleganza> Hi! Is there a way to combine two ECDSA signatures S1 and S2 so the result is a valid signature with private key = privkey1*privkey2 ?
273 2014-01-21 09:09:04 <brisque> CodeShark: more likely the recipient isn't even online and might not ever be.
274 2014-01-21 09:09:39 <CodeShark> yes, this is all true - I was thinking about an ideal situation where these issues could be solved in some other manner
275 2014-01-21 09:11:00 <CodeShark> anyhow, it is clearly not a trivial problemâ¦and there might not be an ideal solution
276 2014-01-21 09:11:52 <brisque> block storage will become an issue long before links are saturated. bandwidth is cheap.
277 2014-01-21 09:14:56 <CodeShark> the main reason for relayers requiring a fee is to prevent spam - however, since the fee gets paid to miners, relay fee is not really subject to natural market dynamics
278 2014-01-21 09:20:20 <CodeShark> so the issue remains - how to incentivize relay and how to deter spam
279 2014-01-21 09:20:41 <CodeShark> I believe it is as yet an incompletely solved problem at best
280 2014-01-21 09:21:04 <Krellan> Aye
281 2014-01-21 09:21:31 <Krellan> I thought about that myself - no incentive to run a full bitcoin node unless you are mining
282 2014-01-21 09:22:08 <Krellan> that said, I would love to solve the problem I'm having with "mintxfee" and "minrelaytxfee"
283 2014-01-21 09:23:31 <Krellan> mintxfee has no effect unless I'm lucky enough to solve a block (ha) - minrelaytxfee controls both my TX and peer TX and i'd love to separate these two knobs
284 2014-01-21 09:23:47 <warren> wumpus: sorry to nitpick, but did you use "git mv OLDFILE NEWFILE" for this? it appears not.
285 2014-01-21 09:24:16 <warren> wumpus: it's a bit easier to follow simultaneous rename and changes that way
286 2014-01-21 09:34:14 <warren> # http://statmt.org/~s0565741/software/boost_1_52_0/libs/context/doc/html/context/requirements.html
287 2014-01-21 09:34:14 <warren> # Note: Might need these options in the future for 64bit builds.
288 2014-01-21 09:34:20 <warren> wumpus: perhaps that coment isn't needed anymore?
289 2014-01-21 09:37:23 <wumpus> warren: yes, I used git mv
290 2014-01-21 09:37:40 <wumpus> but git isn't very good at tracking renames when the content of files also changed
291 2014-01-21 09:38:34 <wumpus> note that almost the entire files are rewritten (from git's viewpoint) due to the indentation for the for loop
292 2014-01-21 09:39:17 <wumpus> you can use a manual diff + ignore spaces to get a sensible output
293 2014-01-21 09:40:55 <wumpus> removed the boost 64-bit comment, it is taken into account already
294 2014-01-21 09:46:42 <warren> wumpus: ok, my mistake
295 2014-01-21 09:48:30 <fanquake> ;;blocks
296 2014-01-21 09:48:31 <gribble> 281653
297 2014-01-21 11:00:46 <nightlingo> guys... how can you tell when the difficulty level will increase ?
298 2014-01-21 11:01:10 <nightlingo> which are the most significant variables that contribute to this change ?
299 2014-01-21 11:08:29 <brisque> nightlingo: there's one variable, the speed of block generation. the difficulty changes every set number of blocks (2016), and the difficulty is adjusted so that the average time per block is back to 10 minutes. it can increase or decrease, it acts like a governor to keep the speed of block generation constant.
300 2014-01-21 11:09:45 <brisque> nightlingo: the speed of the network is dependant on the hashing power, that is the number of miners and their speeds added together. at the moment it's something like 16 petahash, or a difficulty of 1.7 billion. as we are currently mining too fast (a block every 7 minutes), the difficulty will increase in the next period by something like 25% to compensate.
301 2014-01-21 11:10:43 <warren> wumpus problem ... qt-win.yml fails due to not enough space in the VM disk, did you use on-defaults when creating it?
302 2014-01-21 11:12:08 <wumpus> warren: I don't know, seems to work fine for me, but it'd be possible to rm the build directories after use
303 2014-01-21 11:19:58 <wumpus> personally I prefer not to, as it can be useful to ssh to the vm and inspect the result in some cases, but what else can we do if it runs out of disk space
304 2014-01-21 11:20:27 <wumpus> it would only clean up on succesful builds, obviously
305 2014-01-21 11:21:23 <Krellan> Nice, my little patch got accepted into pywallet - that makes 4 for 4 with bitcoin tools I've used :)
306 2014-01-21 11:24:02 <wumpus> warren: can you try adding a rm -rf $BUILDDIR $DEPSDIR before the done?
307 2014-01-21 11:24:36 <wumpus> oh even $INSTALLPREFIX can be in there
308 2014-01-21 11:24:55 <warren> wumpus: will do so if it fails again, trying
309 2014-01-21 11:32:33 <wumpus> qt sure makes a lot of files during build, so it somehow makes sense that it runs out of space
310 2014-01-21 11:32:51 <sipa> Krellan: isn't there a -txfee to set the volynatary fee per kb?
311 2014-01-21 11:34:22 <nightlingo> brisque: thanks! that was an awesome explanation :)
312 2014-01-21 11:34:56 <Krellan> sipa: I wonder if both of those options (-txfee on command line, mintxfee in bitcoin.conf file) set the same setting?
313 2014-01-21 11:34:58 <sipa> jcorgan: bip32/38/39 don't affect the network protocol, it's just individual clients that choose or choose not to adopt it
314 2014-01-21 11:36:05 <sipa> swulf--: the genesis block has height 0
315 2014-01-21 11:36:30 <Krellan> Will have to look at it some more. Strange that all the txfee settings wouldn't be in one place.
316 2014-01-21 11:36:31 <adam3us> anyone have a bookmark for that long article someone made on bitcointalk giving a code walk through of bitcoind?
317 2014-01-21 11:36:53 <adam3us> explaining the structure, classes, code organization etc. cant find link now.
318 2014-01-21 11:38:59 <sipa> Krellan: one is mining, one is wallet, one is validation
319 2014-01-21 11:39:25 <sipa> Krellan: there's even a settxfee rpc iirc
320 2014-01-21 11:39:31 <Krellan> sipa: good, that's the idea
321 2014-01-21 11:39:48 <Krellan> glad to see that's already there, I missed it entirely
322 2014-01-21 11:40:20 <warren> wumpus: PM
323 2014-01-21 11:40:23 <warren> wumpus: trying your suggestion now
324 2014-01-21 11:44:02 <adam3us> adam3us: ah never mind, i found it finally https://bitcointalk.org/index.php?topic=41718.0
325 2014-01-21 11:48:40 <sipa> adam3us: not sure how up to date that is
326 2014-01-21 11:49:08 <sipa> adam3us: with headers-first at least the downloading mechanism will change significantly
327 2014-01-21 13:01:54 <warren> wumpus: Running the win64 bitcoin-qt.exe it thinks my existing block database is corrupted.
328 2014-01-21 13:02:10 <warren> wumpus: on this computer I didn't use bitcoin since February 2013 apparently
329 2014-01-21 13:02:20 <warren> it's leveldb
330 2014-01-21 13:02:54 <warren> I'm aborting rebuild of block database and making a copy
331 2014-01-21 13:03:16 <wumpus> strange, wouldn't know what to think about it, worked fine for me (even though I've run the 32-bit exe before)
332 2014-01-21 13:04:10 <wumpus> it just picked up from where it was
333 2014-01-21 13:04:11 <warren> wumpus: it also installed the 64bit binary in C:\Program Files (x86)\Bitcoin\ which is wrong
334 2014-01-21 13:04:22 <wumpus> warren: see the post in the github issue
335 2014-01-21 13:04:25 <warren> ah
336 2014-01-21 13:04:27 <wumpus> that's already known...
337 2014-01-21 13:05:21 <warren> it would save a LOT of time if there were gitian nightly builds available for download ...
338 2014-01-21 13:05:54 <wumpus> yes it would be useful
339 2014-01-21 13:06:06 <wumpus> feel free to set up something like that
340 2014-01-21 13:06:19 <warren> I travel soon, thinking about doing it.
341 2014-01-21 13:07:21 <wumpus> I think the biggest issue is hosting
342 2014-01-21 13:07:32 <warren> download hosting or the build box?
343 2014-01-21 13:07:36 <warren> download hosting isn't a big problem
344 2014-01-21 13:07:45 <wumpus> the building could be done on the same box that does pulltester, I think
345 2014-01-21 13:08:20 <wumpus> I think download hosting (bandwidth) is a larger issue
346 2014-01-21 13:08:43 <warren> I have some capacity for that
347 2014-01-21 13:08:49 <warren> but it comes out of my pocket
348 2014-01-21 13:08:58 <wumpus> not sure though, I've never tried something like that
349 2014-01-21 13:09:37 <warren> I'm back home in 2 weeks, I'll see about implementing auto-builds
350 2014-01-21 13:10:10 <wumpus> if you can provide the scripting and post on the ML someone else may be able to provide hosting
351 2014-01-21 13:10:34 <warren> hmm... win32 build also thinks my block database is corrupted
352 2014-01-21 13:10:53 <wumpus> as I'm sure you're not the only person who thinks this would be useful
353 2014-01-21 13:10:55 <warren> wumpus: and that cmd.exe console window still opens
354 2014-01-21 13:11:00 <wumpus> oh, phew, no 64-bit issue
355 2014-01-21 13:11:15 <warren> well
356 2014-01-21 13:11:24 <warren> ACTION tests 0.8.6
357 2014-01-21 13:11:32 <wumpus> warren: yes, no one fixed that yet
358 2014-01-21 13:12:13 <warren> wumpus: for the windows installer could we put the source into a .zip file that is installed alongside instead of an exploded source tree that 0.01% of the end users will actually care about?
359 2014-01-21 13:12:16 <wumpus> neither is issue #3499 closed
360 2014-01-21 13:12:32 <wumpus> warren: dunno, open an issue for that
361 2014-01-21 13:12:47 <wumpus> I think it's brought up before and it was decided to keep it like this
362 2014-01-21 13:12:48 <warren> I'd suggest the same thing for the linux tar
363 2014-01-21 13:12:58 <wumpus> a long time ago though...
364 2014-01-21 13:13:04 <warren> well, it slows down install, and due to filesystem slack it wastes more disk space, and almost nobody wants it
365 2014-01-21 13:13:40 <wumpus> well on the other hand if you install bitcoin-qt in the first place you should have plenty of disk space, that text for the source code is nothing compared to the block chain :p
366 2014-01-21 13:13:59 <warren> wumpus: bad ... 0.8.6 doesn't think the block database is corrupted
367 2014-01-21 13:14:11 <wumpus> penny wise pound foolish
368 2014-01-21 13:14:58 <wumpus> anything in debug.log as to *why* it thinks it is corrupted?
369 2014-01-21 13:15:11 <warren> no
370 2014-01-21 13:15:25 <warren> it's past 3am here, I'll look later
371 2014-01-21 13:18:01 <warren> wumpus: crap. after running 0.8.6, the new master build no longer thinks its corrupt ...
372 2014-01-21 13:21:22 <warren> wumpus: hm, the rotating icons in the bottom right are missing
373 2014-01-21 13:21:28 <warren> wumpus: it's just blank there
374 2014-01-21 13:21:41 <wumpus> lol !define: "MUI_UNWELCOMEFINISHPAGE_BITMAP"="/home/ubuntu/build64/distsrc/share/pixmaps/nsis-wizard.bmp" ... so there's an UNWELCOME page too? :p
375 2014-01-21 13:21:57 <wumpus> warren: didn't have that issue
376 2014-01-21 13:22:20 <warren> wumpus: I see nothing there in windows 7 64bit
377 2014-01-21 13:22:30 <wumpus> while syncing?
378 2014-01-21 13:22:33 <warren> wumpus: yes
379 2014-01-21 13:23:21 <wumpus> ok, no idea...
380 2014-01-21 13:23:51 <wumpus> that's a small detail I suppose, I wonder if the overal program is stable and working
381 2014-01-21 13:24:04 <wumpus> if not we can still cancel this 64 bit idea
382 2014-01-21 13:24:35 <warren> hmm, whatever master is doing with upnp works with Apple Time Capsule's NAT. 0.8.6's upnp didn't.
383 2014-01-21 13:24:41 <warren> perhaps that's from the dep upgrade?
384 2014-01-21 13:24:58 <warren> this might get us more listening nodes
385 2014-01-21 13:25:03 <wumpus> yes I think so, UPNP is also working for me now
386 2014-01-21 13:26:03 <warren> wumpus: *strange*, actual block sync didn't begin until I opened the Debug window, prior to that I had 13 peers connected ...
387 2014-01-21 13:26:21 <wumpus> that's pretty normal, don't panic too soon
388 2014-01-21 13:26:37 <warren> network traffic graph is nice
389 2014-01-21 13:26:50 <warren> I'm leaving the office now, will leave this running
390 2014-01-21 13:26:54 <warren> flying in two days
391 2014-01-21 13:26:58 <warren> bbl
392 2014-01-21 13:26:59 <wumpus> thanks for testing
393 2014-01-21 13:27:01 <wumpus> later!
394 2014-01-21 13:27:04 <warren> ttyl
395 2014-01-21 14:23:56 <berndj> i want to relax the requirement for the first cert in a payment request's pki_data to be the request's signing cert. path of lest resistance is to just cycle through all the certs until i find one that works; would it be better to add a field to say the first N of pki_data's certs are the ones to look at?
396 2014-01-21 14:24:18 <berndj> also, i'm not sure how openssl feels about the ordering of certs
397 2014-01-21 14:29:41 <TD> berndj: openssl requires certs to be ordered
398 2014-01-21 14:29:56 <berndj> drat
399 2014-01-21 14:29:57 <TD> berndj: why do you think it's easier to brute force it rather than just rely on the order in the pki_Data?
400 2014-01-21 14:30:54 <berndj> TD, http://lair.fifthhorseman.net/~dkg/tls-centralization/ (search for "encourage concentration") - that's what i want to address
401 2014-01-21 14:31:50 <berndj> does it require a linear ordering or merely a topological order?
402 2014-01-21 14:32:36 <TD> you can already cross-sign certificates. X.509v3 allows complex topologies
403 2014-01-21 14:32:46 <TD> in practice nobody uses this because being signed by two CA's is a waste of time
404 2014-01-21 14:33:08 <TD> besides, i question the rationale on that page. there is quite a lot of competition in the CA market
405 2014-01-21 14:34:14 <TD> the stated modification wouldn't help competition. people would still say, "i want 100% acceptance of my SSL, even on old/crappy embedded devices that never receive any kind of update. therefore i will need to buy a cert that has a high degree of acceptance. now i don't need a second cert, so why bother?"
406 2014-01-21 14:34:30 <TD> the right way to make it easier to create new CA's is to do what Microsoft already did in Vista, and make root certs downloaded just in time
407 2014-01-21 14:34:47 <TD> (or ensure that software updates work reliably and people apply them)
408 2014-01-21 14:35:31 <TD> there is a debate on this running in the bitcointalk forum at the moment, if you want to read that
409 2014-01-21 14:36:02 <berndj> TD, you're presenting the incentive in choosing a CA as binary
410 2014-01-21 14:36:11 <TD> it is binary
411 2014-01-21 14:36:39 <berndj> yes, i'll buy a cert from $biggest_ca, but i can *also* buy one from $tinfoil_hat_ca
412 2014-01-21 14:36:39 <TD> either you get the effect in the UI you want, or you don't. for browsers that means, the user sees the padlock or they don't
413 2014-01-21 14:36:56 <TD> you can do it with SSL today and nobody ever does. because it's a waste of time. why would you buy a second cert from tinfoil hat ca?
414 2014-01-21 14:37:11 <TD> all you care about is whether the user sees the padlock. do they see it? yes? job done
415 2014-01-21 14:37:20 <TD> there is zero benefit to having a second CA check the same thing
416 2014-01-21 14:38:12 <berndj> ok, so you're saying that if someone *did* get their paymentrequest signing cert signed by two CA's, bitcoin-qt would show the coveted green request regardless of which (single) CA cert it trusts?
417 2014-01-21 14:38:24 <TD> of course. how else should it work? you want to see a screen that's twice as green?
418 2014-01-21 14:38:27 <berndj> as in right now, not with some patch applied
419 2014-01-21 14:38:55 <berndj> lol, i want #01FE00!
420 2014-01-21 14:39:07 <TD> no, i mean, the code would probably reject if you tried to present two separate cert chains
421 2014-01-21 14:39:26 <berndj> seriously, i just thought that it would show red in one of the cases
422 2014-01-21 14:39:32 <TD> i've never tried it. you can certainly get a cert that's cross-signed by two CAs, but it requires the CA's to co-operate I believe today and (because this is pointless) none of them have any UI set up for that
423 2014-01-21 14:39:59 <Matt_von_Mises> What is the justification for having so much code randomly within the header files of the Satoshi client? It makes code hard to find and every time I change a bit of code in the header file it forces recompilation of everything that includes it, which is annoying as the Satoshi client takes ages to build.
424 2014-01-21 14:40:04 <TD> but there's no point in trying to "fix" this because any UI that tries to be more than a binary green/grey system will confuse people
425 2014-01-21 14:40:13 <berndj> ok that seems like a red flag to me. it shouldn't depend on CAs cooperating
426 2014-01-21 14:40:18 <TD> Matt_von_Mises: it's just the way Satoshi wrote it and it's being slowly changed over time
427 2014-01-21 14:40:51 <Matt_von_Mises> TD: I hope so! It's still quite a mess.
428 2014-01-21 14:41:12 <TD> berndj: again, I never tried it. it might work. depends on the toolchains they use, i think. generally CA's are conservative about what they sign, for obvious reasons ...... it's generally a bad idea, security wise, to sign random crap you don't understand
429 2014-01-21 14:41:14 <berndj> TD, i'm not trying to make green greener. i just want red to become green if there is a valid humanly-verifiable chain of trust back to something the client does trust
430 2014-01-21 14:41:31 <TD> hmmm, about to run out of battery. just a sec ... gonna have to find a power plug
431 2014-01-21 14:42:19 <jgarzik> Matt_von_Mises, TD, RE "just the way Satoshi wrote it" -- Satoshi was following common C++ coding style at the time, which often puts lots of code in header files
432 2014-01-21 14:42:25 <jgarzik> It is a not-uncommon C++ style
433 2014-01-21 14:42:54 <jgarzik> In general, Satoshi lumped code together in an annoying fashion
434 2014-01-21 14:43:20 <TD> darn. can't find a socket :(
435 2014-01-21 14:43:25 <TD> ok well will try and come back later
436 2014-01-21 14:43:59 <TD> anyway, think through what you're proposing in more detail - there are NO situations in which i will want to sign with a CA that some clients don't trust, if there's a set that all of them do trust. the only way to solve that is to get acceptance of new CA's to 100% as fast/easily as possible
437 2014-01-21 14:44:07 <TD> (given that a cert is a commodity)
438 2014-01-21 15:00:43 <berndj> dunno, i'm not convinced. everything i read about x509 says there's only one issuer
439 2014-01-21 15:26:01 <TD> back
440 2014-01-21 15:26:20 <TD> seems like starbucks has some weird filtering policies in place. SSL stripping on google.com and interference with IRC connections :(
441 2014-01-21 15:28:25 <TD> berndj: sorry for the interruption
442 2014-01-21 15:30:04 <berndj> no worries
443 2014-01-21 15:30:04 <berndj> TD, from what i can find there's room for only one issuer in a certificate, and this "cross-signing" you're presenting as the extant solution is a separate mechanism, have i got that right so far?
444 2014-01-21 15:30:30 <berndj> (i really don't know much other than some very short TL;DR version of x509)
445 2014-01-21 15:32:05 <berndj> my position is: it may be that "nobody's interested in having multiple issuers", but i don't like the idea of codifying that into the payment protocol
446 2014-01-21 15:37:15 <TD> berndj: it's a part of x.509 v3 but that's fairly deep voodoo
447 2014-01-21 15:37:21 <TD> berndj: i dunno how good implementation support is
448 2014-01-21 15:37:36 <TD> berndj: well every time you increase the complexity of the payment protocol, you add work for volunteers to do
449 2014-01-21 15:37:41 <TD> so it's not like it's free to just throw stuff in there
450 2014-01-21 15:37:47 <TD> each feature has to be justified by its cost
451 2014-01-21 15:38:13 <TD> the only case in which multiple chains would help is if wallets ended up with a disjoint set of root CAs, which would be a disaster and is very unlikely to happen
452 2014-01-21 15:38:29 <TD> what was the problem you were trying to solve, again? competition in the CA market?
453 2014-01-21 15:38:35 <berndj> i don't find it that unlikely
454 2014-01-21 15:39:45 <TD> you have little faith in us :)
455 2014-01-21 15:39:57 <berndj> if i were a bitcillionaire i wouldn't like having to just accept that all zillion of the OS-loaded root CAs are benevolent - i'd want to be able to choose some tinfoil hat root CA and also be able to *not* trust the standard ones
456 2014-01-21 15:40:09 <TD> ok. so don't trust the standard ones.
457 2014-01-21 15:40:22 <TD> go delete the rest
458 2014-01-21 15:40:42 <berndj> but that leaves be with yellow (not red - i misspoke earlier) bars instead of the coveted green!
459 2014-01-21 15:42:56 <TD> that sounds like a bug. it should be grey, same as any other unsigned payment request
460 2014-01-21 15:43:18 <TD> sigcheck failure should be treated as equivalent to unsigned. tsk.
461 2014-01-21 15:43:22 <TD> well, we can fix that
462 2014-01-21 15:43:43 <TD> anyway yes - tinfoil-hat land is a lonely place. the seller trusts entity A and you don't. what to do ?
463 2014-01-21 15:45:16 <berndj> what i want is for the seller to be able to have their certificate signed by *both* $common_CA *and* $tinfoil_hat_CA
464 2014-01-21 15:45:31 <TD> why would they care to do that? you're the one wearing the tinfoil hat, not them
465 2014-01-21 15:45:34 <TD> they trust A, remember
466 2014-01-21 15:46:02 <berndj> how do they trust A? A trusts them, so isn't it the other way round?
467 2014-01-21 15:46:33 <TD> they went to A and asked for ID verification. obviously they trust A to do a good job of that, otherwise they would not have handed over money for the service. they could have gone to tinfoil hat CA instead, right?
468 2014-01-21 15:46:50 <berndj> well if they know that their market contains many tinfoilhatters, they'd want to accommodate the tinfoilhatters' CA choices, no?
469 2014-01-21 15:46:50 <TD> A does *not* trust them!
470 2014-01-21 15:47:06 <TD> A explicitly doesn't trust them. That's why A does various checks to ensure A is who they say they are, and gets audited to ensure they're doing those checks
471 2014-01-21 15:47:22 <TD> berndj: so then why not just switch to tinfoil hat CA for everyone?
472 2014-01-21 15:47:29 <berndj> ok, we're using different versions of "trust"
473 2014-01-21 15:47:55 <berndj> why does the seller care how good a job the CA does? it's the *buyers* who care
474 2014-01-21 15:49:22 <TD> indeed. the seller cares that they are verified to the level that ensures the buyers wallet will trust that verification
475 2014-01-21 15:49:43 <TD> so the seller cares that the CA does a good enough job to satisfy the wallet developers, essentially (for the majority case where users delegate CA trust)
476 2014-01-21 15:50:06 <TD> if lots of users are editing their root key stores (this will never happen), then we change it to say the seller cares that the CA does a good enough job to satisfy the buyer
477 2014-01-21 15:51:32 <berndj> the seller cares, but what they care about is whether the CA's certificate is in the buyers' wallet software, not directly whether the CA does a good job
478 2014-01-21 15:51:50 <TD> if the CA doesn't do a good enough job to satisfy the wallet developers, it's supposed to get removed, so they care transitively
479 2014-01-21 15:52:02 <TD> establishing trust is hard work so that's why it gets delegated
480 2014-01-21 15:52:18 <berndj> heh, not sure i like the law of transitivity of caring
481 2014-01-21 15:52:37 <TD> it's human. why do we have brands?
482 2014-01-21 15:52:46 <TD> why am i in a starbucks right now and not a mom'n'pop cafe?
483 2014-01-21 15:53:13 <TD> well, because i was wandering around london and saw a starbucks. and i know they'll have free wifi and i trust in what experience i'm going to get, because their brand is very consistently enforced.
484 2014-01-21 15:53:17 <BlueMatt> SomeoneWeird: 20 :)
485 2014-01-21 15:53:20 <lifeofcray> well bitcoin devs
486 2014-01-21 15:53:24 <TD> hey BlueMatt
487 2014-01-21 15:53:27 <BlueMatt> hi TD
488 2014-01-21 15:53:33 <lifeofcray> anyone got some nice small scripts to sell?
489 2014-01-21 15:53:40 <helo> lifeofcray: #bitcoin-otc
490 2014-01-21 15:53:45 <lifeofcray> maybe a lil' gamling script or something
491 2014-01-21 15:53:57 <TD> although that said, it turns out that recently starbucks started SSL stripping and screwing with IRC, so now my trust in them is damaged a little. next time i'll try a bit harder to find a costa :)
492 2014-01-21 15:53:58 <lifeofcray> otc is mainly for trading the coin
493 2014-01-21 15:54:03 <lifeofcray> not all that many coders
494 2014-01-21 15:55:12 <berndj> anyway i'm not going to convince you that what i want to do is worthwhile, and i don't think you'll convince me that it isn't; interesting chat though
495 2014-01-21 15:56:02 <TD> i understand the desire, i just disagree that what you think will work, would actually work
496 2014-01-21 15:56:24 <berndj> so far i don't think anyone but the monkeysphere people see it as something worthwhile; i guess that's your cue to say something like "well maybe it isn't worth doing then" :)
497 2014-01-21 15:56:36 <TD> you could have your tinfoil hat CA compile lists of pubkeys/cert hashes that it says are "trusted", though i don't think it's meaningful to mark an identity as verified if that entity isn't co-operating with you
498 2014-01-21 15:57:03 <TD> if you can find a way to verify an identity *without* them co-operating, you could come up with an out of band method for this. for the specific case of domain names only, Convergence is an example of this
499 2014-01-21 15:57:15 <TD> it doesn't generalise to other kinds of ID though
500 2014-01-21 15:58:49 <berndj> well what i wanted to do is perhaps such an out-of-band method? i wanted to just relax the requirement for pki_data[0] = seller's cert, but if openssl is really fascist about certificate order, it'll be a lot more work than just adding a for loop
501 2014-01-21 15:59:57 <TD> to add out of band verification you don't need to use openssl at all
502 2014-01-21 16:00:07 <TD> you just pick the first cert and go ask your third party tinfoilhat service "do you trust this cert?"
503 2014-01-21 16:00:34 <TD> or to be more accurate, "this cert claims to be issued for john@smith.com - was it?"
504 2014-01-21 16:01:39 <berndj> that introduces an asymmetry i don't like
505 2014-01-21 16:01:59 <berndj> asymmetry = concentrating force
506 2014-01-21 16:02:16 <TD> how so
507 2014-01-21 16:03:14 <berndj> by treating one certificate chain as the default, with all the convenience that entails, but requiring special action for another, that's a tax on the second
508 2014-01-21 16:04:13 <berndj> and here the tinfoil hat CA becomes a counterproductive example, because if you're wearing one of those hats, you possibly *do* want the inconvenience of non-default action
509 2014-01-21 16:05:26 <TD> well, right. now i'm confused. you want to do something that is, by definition, out of the ordinary, because you don't trust entities that are trusted by default.
510 2014-01-21 16:05:30 <berndj> just imagine it's 1995 and i'm in south africa (i am actually) and thawte rules the world here, its cert is loaded everywhere and verisign's isn't. you have the opposite scenario. but we both buy an ad-free subscription to dejanews
511 2014-01-21 16:05:33 <TD> so how else do you solve that except by going out of band
512 2014-01-21 16:06:17 <TD> yeah, well that's the disaster scenario i mentioned. the solution in this case wasn't to make everyone pointlessly buy two certs but rather for browser makers to come up with standards for what it takes to be accepted as a root CA, and then they all came into agreement and trusted both
513 2014-01-21 16:07:12 <berndj> ok, fair enough. i think that's where you an i disagree. i think you're saying, "problem solved right there", and i'm saying, "let's not repeat the mistake that led to that disaster"
514 2014-01-21 16:08:26 <TD> yeah, well that's why i'm planning to make bitcoinj have a standard set of root certs ship with it. so for all bitcoinj based wallets at least you can always be sure that your payment request will be accepted as signed. perhaps in future we'll give it a JIT downloader just like Vista+
515 2014-01-21 16:08:47 <TD> so once a CA becomes trusted, it gets trusted by everyone simultaneously. Trezor might be an issue ...
516 2014-01-21 16:09:18 <TD> i think there we probably want to externalise the root CA store and have the wallet app provide a merkle branch to a root that's signed by the Trezor team
517 2014-01-21 16:10:09 <TD> the interesting work, from my perspective, is can we define some kind of standard for how to be a low-quality/adhoc CA
518 2014-01-21 16:10:45 <TD> one reason it's hard to compete with the current CA's, even if everyone used Microsoft's design, is that the quality standards are very high
519 2014-01-21 16:10:45 <TD> so it's expensive to set one up
520 2014-01-21 16:10:58 <TD> smaller CA's that aren't as critical, just for the bitcoin community, would be useful, if we could agree what it means to be "not as critical" and what that means
521 2014-01-21 16:12:24 <kinlo> TD: in how far can you sign the CA's with another parent CA? I always wondered why browsers wouldn't just create 1 master CA and use the sign/revoke system whenever they want.
522 2014-01-21 16:12:52 <kinlo> it will require some adjustments to the protocol, as a CA is usually self-signed, and you'll have to provide a detached signature to build the chain
523 2014-01-21 16:13:03 <kinlo> but in the end it does make sense
524 2014-01-21 16:15:24 <TD> kinlo: CA's effectively have multiple parent "authorities" (each operating system or app that uses the system). you don't really want every CA to have to get signed by every OS, as each signing changes the cert. detaching the signatures would solve that, but at this point it stops being simpler imo ....
525 2014-01-21 16:15:45 <epscy> kinlo: i think that would lead to creating and distributing fake versions of browsers with bad CA's in them
526 2014-01-21 16:15:45 <TD> kinlo: how far - depends on the path length constraints in the parent certs. in theory you can go up quite far (i guess openssl supports hundreds but nobody ever does that)
527 2014-01-21 16:16:36 <kinlo> epscy: the entire CA idea is broken by design, so I'm not worried about that... They can distribute fake browsers right now already
528 2014-01-21 16:16:59 <TD> hah
529 2014-01-21 16:17:47 <kinlo> TD: well, the detached signatures would make it more complex, but it would allow re-use of the ocsp and crl system to revoke certificates, and to add new certificates without requiring to "patch" the code
530 2014-01-21 16:18:21 <TD> you don't have to patch code now. root certs are stored in a kind of lightweight database on most platforms. like i said, on windows certs are downloaded on the fly if they're missing
531 2014-01-21 16:18:34 <kinlo> are they?
532 2014-01-21 16:18:45 <TD> sure, since vista. other platforms could do the same
533 2014-01-21 16:18:48 <TD> i don't think they do though
534 2014-01-21 16:18:53 <kinlo> intermediates are offered by the servers, but root certificates?
535 2014-01-21 16:19:11 <TD> root certs are not a part of the offered chain
536 2014-01-21 16:19:16 <kinlo> how can they be downloaded on the fly? How are they verified?
537 2014-01-21 16:19:40 <TD> the windows API code is given a cert chain to verify. if it chains to an unknown root, it goes and makes a request to microsoft servers saying "do you know about this root?"
538 2014-01-21 16:19:52 <TD> and microsoft sends back a (presumably signed) response saying "yes, here you go". then it's stored/cached
539 2014-01-21 16:20:28 <kinlo> well, "presumably signed" is quite important here :)
540 2014-01-21 16:20:34 <TD> i assume microsoft didn't screw it up
541 2014-01-21 16:20:38 <TD> i never looked into the details
542 2014-01-21 16:20:59 <kinlo> if they aren't signed, you basically can just hijack any computer on your network with ease
543 2014-01-21 16:21:41 <kinlo> anyway, so microsoft basically does what I'm proposing in other words - use detached signatures (well, hopefully) to identify root's
544 2014-01-21 16:21:59 <TD> sort of
545 2014-01-21 16:22:01 <TD> i guess so
546 2014-01-21 16:22:09 <TD> it's just not a part of SSL or anything
547 2014-01-21 16:22:29 <kinlo> too bad
548 2014-01-21 16:22:31 <TD> i mean the detached signature doesn't have to be offered by the signer
549 2014-01-21 16:23:05 <kinlo> but if I'm not mistaken, a CA is referred by the signature of it's public key
550 2014-01-21 16:23:32 <kinlo> you can create 2 CA's which are equally accepted as the parent of a public key, with completly different data in them
551 2014-01-21 16:23:53 <kinlo> as long as they are created based on the same public key (and not self-signed coz then you'd need the private key too)
552 2014-01-21 16:24:11 <kinlo> so maybe it is possible to just rewrite the root ca's to have one common ancestor
553 2014-01-21 16:24:17 <kinlo> using the default CA protocol
554 2014-01-21 16:24:38 <kinlo> I'd have to verify this, but I remember once having two root certificates, both valid for the same child
555 2014-01-21 16:25:26 <kinlo> just need a download protocol to distribute those new root certificates
556 2014-01-21 16:36:22 <TD> hmm
557 2014-01-21 16:38:29 <TD> coffee shop wifi is annoying :)
558 2014-01-21 16:39:04 <sipa> 4G go go go
559 2014-01-21 16:39:33 <TD> i need to buy a pay as you go card for the UK, though then my number would change.
560 2014-01-21 16:39:40 <TD> telcos suck. sigh.
561 2014-01-21 16:47:47 <TD> sipa: if you don't mind i'm thinking of rewriting most of BIP32
562 2014-01-21 16:47:56 <TD> sipa: i find the current way it's written to be very confusing
563 2014-01-21 16:48:05 <sipa> TD: if you can clarify things, sure
564 2014-01-21 16:48:19 <sipa> but i'd like to know how/what you'd change things in advance, though :)
565 2014-01-21 16:48:30 <sipa> TD: i paid for my .be data/phone using BTC, btw :)
566 2014-01-21 16:48:46 <TD> nice :)
567 2014-01-21 16:49:03 <TD> i would:
568 2014-01-21 16:49:09 <TD> 1) scrap the use of ' notation everywhere. also scrap the use of greek letters.
569 2014-01-21 16:49:23 <sipa> well, if you have alternatives, sure
570 2014-01-21 16:49:26 <TD> 2) merge CKD and CKD' into one algorithm and scrap the private vs public key derivation function distinction
571 2014-01-21 16:49:42 <TD> i'd probably try and call it key neutering everywhere
572 2014-01-21 16:49:47 <sipa> how can you merge them? they operate on different data types
573 2014-01-21 16:50:20 <sipa> the naming private/public is conflated in several ways in the document, avoiding those terms would certainly be welcome
574 2014-01-21 16:51:05 <TD> indeed. the prime notation is deeply problematic as well - if you read CKD' as "CKD public" then it's natural to assume that 0' means "zero public derivation". in fact it is defined to mean "zero private derivation"
575 2014-01-21 16:51:12 <TD> that switcharoo has given me a headache several times
576 2014-01-21 16:51:36 <sipa> perhaps this would make sense: have a diagram with 4 nodes (parent public, parent private, child public, child private)
577 2014-01-21 16:51:49 <sipa> with all arrows between them explained
578 2014-01-21 16:51:50 <TD> one thing that has been causing confusion for me is that i'm implementing the key hierarchy to not store private keys for leaf nodes ever, and rederive them on the fly
579 2014-01-21 16:52:08 <TD> and in an encrypted hierarchy, i need to derive a pubkey only "watching" key from a parent key where the private key bytes are encrypted (i.e. not available)
580 2014-01-21 16:52:22 <TD> so this confusion between private and public derivation rapidly makes the code unreadable
581 2014-01-21 16:53:08 <sipa> i've asked several people for suggestions for the 0 vs 0' distinction (and calling it private/public, even with different notation, is still confusing)
582 2014-01-21 16:53:18 <sipa> maybe private-only subkey
583 2014-01-21 16:53:39 <TD> the whole notion itself is just horribly confusing :) what it's doing is "neutering" a key
584 2014-01-21 16:53:52 <TD> but in such a way that it doesn't work how you would imagine it works
585 2014-01-21 16:54:09 <TD> you know, i derive a key tree from a seed. so far so good. now i want to hand out a watching wallet
586 2014-01-21 16:54:12 <TD> what do i do?!
587 2014-01-21 16:54:20 <sipa> hmm, neutering has been used (though not in the BIP, iirc) to go private->public
588 2014-01-21 16:54:46 <sipa> the /n' derivation (however you want to call it) is one that exactly prevents neutering
589 2014-01-21 16:54:52 <sipa> (in that meaning)
590 2014-01-21 16:55:06 <TD> this whole spec is so confusing i strongly suspect we will find there are interop problems after it's implemented :(
591 2014-01-21 16:55:22 <sipa> that's a very good reason to improve it
592 2014-01-21 16:55:36 <sipa> but i'd like to hear a more concrete proposal for how you'd explain things first
593 2014-01-21 16:55:36 <TD> yes so when you have /0 without the prime marker, that means it's been neutered, right?
594 2014-01-21 16:55:44 <sipa> no?
595 2014-01-21 16:55:47 <TD> to explain it better i have to understand it, and i can't
596 2014-01-21 16:55:52 <TD> so perhaps you have to do it :)
597 2014-01-21 16:56:16 <sipa> the <key/.../../..> notation doesn't refer to private vs public
598 2014-01-21 16:56:20 <sipa> it's just keys
599 2014-01-21 16:56:35 <TD> right, it refers to which algorithm to run (CKD vs CKD')
600 2014-01-21 16:56:40 <sipa> no
601 2014-01-21 16:56:43 <sipa> not that either
602 2014-01-21 16:57:03 <sipa> CKD is a function to go from parent private key to child private key
603 2014-01-21 16:57:24 <TD> yes, right, it sets the high bit when CKD is run
604 2014-01-21 16:57:27 <sipa> CKD' is a function to go from parent public key to child public key, and can only be used if the derivation isn't a <n>' one
605 2014-01-21 16:57:34 <sipa> no
606 2014-01-21 16:57:44 <TD> To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.
607 2014-01-21 16:57:51 <sipa> right!
608 2014-01-21 16:58:01 <TD> that's what i mean - the ' mark sets the high bit when CKD is run
609 2014-01-21 16:58:08 <sipa> yes, that's correct - i interpreted your sentence differently
610 2014-01-21 16:58:33 <sipa> sorry, gtg
611 2014-01-21 16:58:34 <TD> oh yes. the spec also contains an unfinished sentence
612 2014-01-21 16:58:40 <TD> Note that the extended public key corresponding to the evaluation of CKD(kext, i) with public derivation (so with i ext, i), with Kext the extended public key corresponding to kext.
613 2014-01-21 16:58:44 <TD> that sentence doesn't parse, gramataically
614 2014-01-21 16:58:46 <TD> ok, see you
615 2014-01-21 17:02:25 <swulf--> Hey.. I'm thinking about the 'getheaders' command and wondering ... there's no way to parallel-ize the download? it's simply <getheaders> <connect headers> <get headers> <connect headers> .. rinse and repeat? Connect headers on 2000 blocks is fast enough that it doesn't make sense to issue getheaders during the connect, does it?
616 2014-01-21 17:04:16 <swulf--> if i knew the hash of every 2000th block in advance, then the getheaders could be thrown against a few peers at a time
617 2014-01-21 17:07:49 <sipa> swulf--: yes, headers-first downloading relies on that
618 2014-01-21 17:08:04 <sipa> first build and verify the headers-chain, and the download the blocks in parallel from all peers
619 2014-01-21 17:10:10 <swulf--> makes sense
620 2014-01-21 17:17:04 <TD> sipa: when deriving m/0'/0 the child key is derived entirely from the parent public key and the chain code?
621 2014-01-21 17:17:25 <sipa> in which step?
622 2014-01-21 17:17:36 <sipa> and when deriving what?
623 2014-01-21 17:17:41 <TD> the last one. deriving 0 from 0'
624 2014-01-21 17:18:07 <sipa> you can either use pub(m/0') and derive pub(m/0'/0) from it using CKD'
625 2014-01-21 17:18:09 <TD> the recommended wallet structure is m/0'/0/0 for the first external key, right
626 2014-01-21 17:18:30 <sipa> or you can use priv(m/0') and derive priv(m/0'/0) from it using CKD, and then convert it to a public key
627 2014-01-21 17:19:22 <TD> ah yes. i mis-read the case of the K in step 4 of CKD
628 2014-01-21 17:19:28 <swulf--> sipa: the wiki says (about getheaders), "Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.". This isn't a concern if the blocklocator goes deep enough and has at least one hash on the best chain, right?
629 2014-01-21 17:19:28 <TD> that makes more sense now
630 2014-01-21 17:19:58 <sipa> swulf--: that's no different from normal syncing
631 2014-01-21 17:20:05 <swulf--> thats what I thought
632 2014-01-21 17:20:07 <swulf--> thanks