1 2014-05-09 00:00:57 <gmaxwell> CodeShark: its really easy to create a vault without the extension; and then it won't find it.
  2 2014-05-09 00:04:26 <sipa> we need a startup sanity check
  3 2014-05-09 00:45:31 <coryfields> sipa: i can handle that in the next few days. Still need to go the libc checks at startup as well, unless I missed someone sneaking that in already
  4 2014-05-09 00:46:15 <coryfields> *need to do
  5 2014-05-09 01:54:13 <shesek> if someone happens to have tons of extra testnet coins, I'd appreciate to get some at n2t7tyoW5LLndXVrzgmm1zVSEkJ8jnbHWj
  6 2014-05-09 01:55:55 <shesek> I need a few tens-hundreds of them for some script, and don't want to drain out the faucets :P
  7 2014-05-09 01:56:15 <lianj> why hundreds?
  8 2014-05-09 01:56:22 <arubi> whoa, that's a lot of coins even for testnet
  9 2014-05-09 01:56:30 <arubi> I can send you 3 :)
 10 2014-05-09 01:57:40 <shesek> I'm sure there are people around holding thousands of them :)
 11 2014-05-09 01:57:52 <shesek> just running a miner on a normal cpu would get you tons of them
 12 2014-05-09 01:57:56 <arubi> I tried asking around a short while ago
 13 2014-05-09 01:58:03 <arubi> you'd be surprised
 14 2014-05-09 01:58:48 <arubi> difficulty is 1.0 now, but i'm guessing there are a few asics on the network
 15 2014-05-09 01:59:12 <shesek> I'm writing something for Bitrated that'll automatically send coins to users testing out the next version... it might consume a lot of coins
 16 2014-05-09 01:59:42 <shesek> but maybe hundreds is a bit too much, a few tens to one hundred would probably suffice
 17 2014-05-09 01:59:48 <arubi> you could work with smaller amounts then
 18 2014-05-09 01:59:51 <survic> shesek: most of the faucets have been drained by people using "dark wallet"
 19 2014-05-09 02:00:42 <survic> should be easy enough to ask somebody with some miners to nab a few hundred blocks for you though
 20 2014-05-09 02:01:13 <shesek> arubi, I am, I'm usually using 0.001-0.01 per output for my own tests, but I still end up using quite a lot in total
 21 2014-05-09 02:01:33 <arubi> I see.. do you want 3 of my 5 testnet coins?
 22 2014-05-09 02:01:36 <shesek> I wanted to mine myself, but someone just started mining with an ASIC a few days ago
 23 2014-05-09 02:02:19 <shesek> arubi, nah, its okay, keep them. thanks though! :)
 24 2014-05-09 02:02:28 <shesek> I was hoping there's someone around with tons of them to spare
 25 2014-05-09 02:03:07 <arubi> np, good luck with the search. I couldn't find easy coins myself
 26 2014-05-09 02:03:54 <shesek> there's that faucet which is pretty good: http://faucet.xeno-genesis.com/
 27 2014-05-09 02:04:28 <arubi> that's what I used at first, yea
 28 2014-05-09 02:08:38 <jrick> shesek: I have 100 I can send you
 29 2014-05-09 02:09:06 <jrick> oh you pasted your address nvm
 30 2014-05-09 02:12:01 <shesek> jrick, got it. Thank you, its much appreciated!
 31 2014-05-09 02:15:42 <gribble> Error: "bitcoin-otc" is not a valid command.
 32 2014-05-09 02:15:42 <survic> ,,bitcoin-otc
 33 2014-05-09 02:15:47 <survic> ugh.
 34 2014-05-09 02:54:21 <michagogo> cloud|shesek: still need coins?
 35 2014-05-09 09:32:50 <shesek> michagogo|cloud, nope, jrick sent me a 100 of them. thanks though :)
 36 2014-05-09 09:35:03 <michagogo> cloud|heh, too late
 37 2014-05-09 09:37:33 <michagogo> cloud|(about 4 hours too late, actually)
 38 2014-05-09 09:45:58 <shesek> michagogo|cloud, oh, wow, that's a lot
 39 2014-05-09 09:46:07 <shesek> I have enough to last for a lifetime :)
 40 2014-05-09 09:46:09 <shesek> thanks!
 41 2014-05-09 10:26:41 <melvster> 'As a recognition for the help and patience of our supporters we decided to organize a TREZOR Summer Party in Prague, the capital of Czech Republic.' -- woot -- hope some of you guys can come ...
 42 2014-05-09 10:28:38 <michagogo> cloud|That would be cool
 43 2014-05-09 10:29:14 <melvster> we had the btc conf in prague back in 2011
 44 2014-05-09 10:29:24 <sipa> were you there, melvster?
 45 2014-05-09 10:29:32 <melvster> sipa: I sure was, were you?
 46 2014-05-09 10:29:33 <michagogo> cloud|
ACTION wonders when those (or a competitor?) will be available to the general public

 47 2014-05-09 10:29:36 <sipa> melvster: yes :)
 48 2014-05-09 10:30:05 <melvster> sipa: maybe we met ... were you at the hard rock cafe the day before ... I had dinner with a few of the core devs ...
 49 2014-05-09 10:30:18 <michagogo> cloud|I see the metal ones shipped yesterday
 50 2014-05-09 10:30:35 <melvster> yeah, cant wait to get mine ...
 51 2014-05-09 10:30:36 <hearn> s/shipped/are shipping/
 52 2014-05-09 10:31:18 <michagogo> cloud|I hope once they're available for sale they are cheaper...
 53 2014-05-09 10:31:37 <michagogo> cloud|It'd be a cool thing to have, but for that money I could buy a couple smartphones
 54 2014-05-09 10:31:39 <hearn> hard to know, isn’t it, given the rocky road they had
 55 2014-05-09 10:31:54 <hearn> beating smartphone prices won’t happen any time soon, i bet.
 56 2014-05-09 10:32:01 <hearn> economies of scale are hard to beat
 57 2014-05-09 10:32:13 <sipa> melvster: i was the only core dev in prague, afaik :)
 58 2014-05-09 10:32:14 <hearn> i’m hoping that they start to sell TREZOR outside of the bitcoin community, for corporate security and other purposes
 59 2014-05-09 10:32:34 <hearn> so they can ramp up production volumes. LOTS of industries need a secure display and two buttons that fits on a keyring
 60 2014-05-09 10:32:34 <sipa> melvster: and i was at the hard rock cafe too
 61 2014-05-09 10:33:44 <melvster> sipa: i might have bought you dinner :)  there was a group of about 6 of us on the right ... was a cool event ...
 62 2014-05-09 10:33:49 <michagogo> cloud|hearn: When were the 1 and 3 BTC prices set?
 63 2014-05-09 10:34:15 <michagogo> cloud|(do you know?)
 64 2014-05-09 10:34:23 <melvster> loooong time ago
 65 2014-05-09 10:34:29 <melvster> when btc was about 100 ish i think
 66 2014-05-09 10:37:26 <melvster> sipa: funnily enough, amir, who organized that conf, found out about bitcoin thru me ... at first he was a sceptic after looking at bitcointalk, but I managed to persuade him it was a cool project
 67 2014-05-09 10:38:03 <michagogo> cloud|http://satoshilabs.com/news/2013-06-14-trezor-pre-sales-launched/
 68 2014-05-09 10:38:26 <michagogo> cloud|So yeah, hovering around 100
 69 2014-05-09 10:38:39 <michagogo> cloud|13:31:54 <hearn> beating smartphone prices won’t happen any time soon, i bet. <-- In other words, that already happened
 70 2014-05-09 10:39:22 <melvster> i used to sit next to marek in the office back then ... and I promised to support the project and ordered a few ... tho technically hearn was the first 'official' pre order :)
 71 2014-05-09 10:39:52 <michagogo> cloud|Cool, didn't know that
 72 2014-05-09 10:40:04 <jouke> Bought some trezors as Christmas gifts for our employees.
 73 2014-05-09 10:40:27 <melvster> anyway I live in prague now ... so if any of you guys are coming for the party, maybe I can help out, or would be cool to meet ...
 74 2014-05-09 10:40:42 <sipa> melvster: i was sitting at a table with gary rowe and jim burton
 75 2014-05-09 10:41:05 <michagogo> cloud|
ACTION wonders if any major Bitcoin event will happen in Israel any time soon

 76 2014-05-09 10:41:19 <michagogo> cloud|(one attended internationally, I mean)
 77 2014-05-09 10:41:21 <melvster> sipa: im terrible with names ... but rings a bell ... so maybe we met already :)
 78 2014-05-09 10:41:36 <sipa> hehe
 79 2014-05-09 10:41:57 <sipa> michagogo|cloud: meni has been trying to invite me for a conference there
 80 2014-05-09 10:42:44 <SomeoneWeird> how about one that somebody pays me to attend
 81 2014-05-09 10:42:47 <SomeoneWeird> that would be awesome
 82 2014-05-09 10:43:00 <SomeoneWeird> c_c
 83 2014-05-09 10:43:24 <michagogo> cloud|If someone were to pay someone to attend, it would probably be someone normal :P
 84 2014-05-09 10:43:31 <SomeoneWeird> aw
 85 2014-05-09 10:43:46 <hearn> michagogo|cloud: eh, smartphones cost <$100 now
 86 2014-05-09 10:43:46 <SomeoneWeird>  /topic Only non-normal people allowed in here.
 87 2014-05-09 10:43:59 <hearn> michagogo|cloud: and that was the pre-order. they didn’t know their own dev costs back then. so. …. we’ll see
 88 2014-05-09 10:44:15 <michagogo> cloud|hearn: huh?
 89 2014-05-09 10:44:30 <hearn> you said it’d already happened?
 90 2014-05-09 10:44:33 <michagogo> cloud|hearn: oh, on a 2-year contract?
 91 2014-05-09 10:44:36 <hearn> o
 92 2014-05-09 10:44:38 <hearn> no
 93 2014-05-09 10:44:41 <michagogo> cloud|o_O
 94 2014-05-09 10:44:55 <hearn> where do you live, btw? the usa?
 95 2014-05-09 10:45:06 <michagogo> cloud|Israel
 96 2014-05-09 10:45:11 <hearn> you can buy $80 or $50 cheap android smartphones with no contract for some time already
 97 2014-05-09 10:45:20 <hearn> they used to be low end gingerbreads but now they’re actually kitkats
 98 2014-05-09 10:45:27 <michagogo> cloud|Oh, cheap android smartphones
 99 2014-05-09 10:45:47 <michagogo> cloud|Not exactly what I had in mind
100 2014-05-09 10:45:49 <sipa> 
ACTION currently actually uses one of those

101 2014-05-09 10:45:57 <hearn> well, i say “cheap” because they are, but they have all the functionality of the high end phones, pretty much
102 2014-05-09 10:46:00 <hearn> the differences are not what you’d expect
103 2014-05-09 10:46:00 <SomeoneWeird> you monster, sipa
104 2014-05-09 10:46:04 <sipa> (because i forgot my nexus 5 in belgium)
105 2014-05-09 10:46:13 <SomeoneWeird> how did you manage that?
106 2014-05-09 10:46:18 <hearn> china + free software + massive economies of scale from selling to the third world + brutal competition == amazing prices
107 2014-05-09 10:46:28 <sipa> by putting it somewhere, and not picking it up again?
108 2014-05-09 10:46:38 <hearn> michagogo|cloud: what did you have in mind when i said “smartphone"?
109 2014-05-09 10:47:06 <sipa> tbh, the statement "smartphones cost <$100" seems to imply that all smartphones are that cheap ;)
110 2014-05-09 10:47:27 <michagogo> cloud|Well, my first thought is an iPhone, perhaps one of Samsung's Galaxy line
111 2014-05-09 10:47:54 <michagogo> cloud|
ACTION slaps Luke-Jr around a bit with a large trout

112 2014-05-09 10:47:57 <hearn> the markup on iPhone’s is insane, nobody uses their prices for calibration anymore. the nexus 5 beats it in every way and costs like $290 or something like that, instead of $700
113 2014-05-09 10:48:09 <michagogo> cloud|
ACTION disagrees

114 2014-05-09 10:48:17 <michagogo> cloud|I've tried Android, and I dislike it
115 2014-05-09 10:48:28 <Luke-Jr> michagogo|cloud: now now, you're the one going off-topic in here promoting a group of armed illegal aliens :P
116 2014-05-09 10:48:43 <hearn> sucks for you - you’re paying >2x for phones that do less. but anyway, there is no debating that these phones are smart  …. check this one
117 2014-05-09 10:48:44 <hearn> http://www.zdnet.com/sub-50-android-smartphone-hits-south-africa-as-mtn-launches-steppa-7000025828/
118 2014-05-09 10:48:50 <michagogo> cloud|...armed illegal aliens?
119 2014-05-09 10:48:53 <hearn> it’s gingerbread but it’s actually less than $50
120 2014-05-09 10:50:19 <hearn> hmm from searching it seems the current rumour is the next nexus phone will be $100 or less. not sure if that’s true. nexus devices are usually competitive/better than iphones
121 2014-05-09 10:50:42 <hearn> anyway here’s one that runs jellybean for $83 .. http://www.amazon.com/BLU-Advance-Unlocked-Phone-White/dp/B00HPTMCRI/ref=sr_1_1?s=wireless&ie=UTF8&qid=1399632597&sr=1-1
122 2014-05-09 10:50:54 <hearn> so yeah. TREZOR is probably going to cost more than a good smartphone
123 2014-05-09 10:51:03 <hearn> but that’s OK. you pay for the security not the features
124 2014-05-09 10:52:19 <sipa> hearn: the majority of people doesn't pay for security :)
125 2014-05-09 10:52:25 <sipa> +want to
126 2014-05-09 10:52:38 <hearn> right :) i guess most bitcoin users (the long tail) will be using risk analysis services that SMS you details of the tx
127 2014-05-09 10:53:11 <hearn> and then heavy users will want to save money on the RA services and buy the hardware. *assuming*, that is, that RA services don’t get flooded with money from silicon valley and simply give away their services for free for years which is something i’m a bit concerned about
128 2014-05-09 10:53:21 <hearn> VC has a nasty habit of totally distorting and breaking markets
129 2014-05-09 10:53:27 <dexX7> hearn: did http://www.bitcoinj.org/working-with-micropayments move?
130 2014-05-09 10:53:48 <hearn> dexX7: DNS is fudged at the moment. use this url: http://bitcoinj.github.io/working-with-micropayments
131 2014-05-09 10:53:59 <dexX7> ah, ty
132 2014-05-09 10:58:11 <hearn> the other thing that could happen is RA services cross-subsidise their consumer service with some other revenue stream, which would also make it hard for trezor to compete
133 2014-05-09 10:58:41 <hearn> i really like the trezor and the guys doing it, but i do worry that it just won’t be competitive in the long run against cheaper less decentralised services
134 2014-05-09 12:17:04 <hearn_> dexX7: bitcoinj.org should be fixed now - sorry for the hassle
135 2014-05-09 12:17:55 <dexX7> no worries, thanks! :)
136 2014-05-09 12:18:32 <hearn_> dexX7: are you planning on doing a micropayment app?
137 2014-05-09 12:18:34 <sipa> hearn_: i have been thinking about an extension to the payment protocol to make the backchannel more reliable
138 2014-05-09 12:18:51 <hearn> 
ACTION is listening

139 2014-05-09 12:19:03 <sipa> hearn_: namely, allowing the payment message to contain a transaction without txins
140 2014-05-09 12:19:38 <sipa> without scriptSigs, sorry
141 2014-05-09 12:19:45 <sipa> hearn: so the payment request would get an extra boolean saying "i will ack payments without scriptSigs"
142 2014-05-09 12:20:08 <sipa> and a paymentACK on a scriptsiglesstx + an accepted tx in the blockchain matching it would be a proof of payment
143 2014-05-09 12:20:28 <sipa> this means you can safely request the ack before actually risking losing money
144 2014-05-09 12:20:49 <sipa> it's even compatible with multiple payments in one bitcoin transaction
145 2014-05-09 12:21:09 <hearn> hmm
146 2014-05-09 12:21:26 <dexX7> hearn: would be really nice, but this was actually only for educational purposes
147 2014-05-09 12:21:29 <hearn> the PaymentACK message is supposed to mean that the merchant actually got the money and is satisfied enough to render the service/provide the goods
148 2014-05-09 12:21:29 <sipa> and since the ack is signed, the memo/refund and any other extra backchannel data is signed by the payee
149 2014-05-09 12:21:38 <hearn> so this would change the meaning of the ACK.
150 2014-05-09 12:21:58 <sipa> ack means "this valid to me"
151 2014-05-09 12:22:14 <sipa> if you double spend it, it's not a valid payment
152 2014-05-09 12:22:54 <sipa> and if something goes wrong on the path from payer to payee, and the memo gets dropped (or modified, or the payee changes it), it means you don't pay them
153 2014-05-09 12:22:57 <hearn> hmm. seems the ACK doesn’t actually have a defined meaning in BIP 70. oops.
154 2014-05-09 12:23:08 <sipa> this would give it a clear meaning
155 2014-05-09 12:23:32 <sipa> "i consider this a valid transaction for the requested payment, assuming it goes through"
156 2014-05-09 12:23:35 <hearn> one of the reasons for the ACK with the memo was to get things like dice sites away from using micropayments as an “answer”
157 2014-05-09 12:23:38 <jouke> But don't you need the scriptsigs to determine if the fee is high enough?
158 2014-05-09 12:23:48 <hearn> this would not work for that.
159 2014-05-09 12:24:07 <sipa> hearn: well then they don't use this functionality
160 2014-05-09 12:24:29 <sipa> i consider having a reliable and uncheatable backchannel pretty essential
161 2014-05-09 12:24:45 <hearn> besides, how does this increase reliability? you still need to communicate with the payment_url. at that point submitting the signed tx doesn’t change anything. once the merchant has sent you the ACK it means you’re getting what you wanted. at that point it’s up to the merchant to ensure they use the tx to actually get paid/confirmed. for instance by broadcasting it, or submitting directly to some miners, or whatever
162 2014-05-09 12:24:47 <sipa> jouke: good point!
163 2014-05-09 12:25:11 <hearn> it seems all this does is move responsibility for broadcast from receipient to sender?
164 2014-05-09 12:25:12 <sipa> hearn: the merchant can broadcast the transaction without acking
165 2014-05-09 12:25:29 <sipa> with this proposal, he can't
166 2014-05-09 12:25:41 <sipa> you can still send the full transaction to them
167 2014-05-09 12:25:47 <sipa> to have them broadcast it
168 2014-05-09 12:25:51 <sipa> in a second phase
169 2014-05-09 12:25:57 <hearn> yes, but does it matter? the ack doesn’t have much meaning, indeed. both sides can still prove the payment happened without the ack. it’s really just there as a messaging system
170 2014-05-09 12:26:06 <sipa> this gives the ack meaning
171 2014-05-09 12:26:13 <sipa> it means you get to disagree with it
172 2014-05-09 12:26:25 <sipa> without risking losing money
173 2014-05-09 12:26:38 <hearn> what kind of disagreement would happen at ACK time that cannot happen when you first read the Payment message
174 2014-05-09 12:27:15 <sipa> the problem i want to solve is make it *impossible* for the bitcoin transaction to go through without both parties agreeing
175 2014-05-09 12:27:37 <sipa> agreeing on the amount, on the scripts used, on the memo used, on the refund used, on the timestamp not being expired, ...
176 2014-05-09 12:27:57 <hearn> i thought that’s what bip 70 already did :) the merchant requests payment for a specific thing, with terms possibly outlined in the memo field, and a signature to prove they wrote it. the upload of a signed transaction signals agreement
177 2014-05-09 12:28:28 <jouke> But the receiver sets the terms and agrees on it beforehand.
178 2014-05-09 12:28:43 <sipa> the merchant can refuse to give you an ack, but still broadcast the transaction
179 2014-05-09 12:29:05 <jouke> and later claim the transaction was not done on time
180 2014-05-09 12:29:15 <hearn> yes but an ACK doesn’t change the nature of the agreement. it’s just a way to display a message on the screen saying “Thanks for your purchase! Have a nice day!” or for dice sites “you won/you lost”. it doesn’t have much value beyond that today.
181 2014-05-09 12:29:30 <sipa> this would give it more meaning
182 2014-05-09 12:29:42 <sipa> namely the ability to disagree with it, and not go through with the transaction
183 2014-05-09 12:29:51 <hearn> i know that’s what you want to do, but i still don’t understand why. it’s meaningless on purpose. you want bip 70 to turn into a multi-step negotiation protocol?
184 2014-05-09 12:30:07 <hearn> surely the right place to do a business negotiation is out of band, with the payment request just representing the final agreement
185 2014-05-09 12:30:12 <sipa> it adds a step, yes
186 2014-05-09 12:30:44 <sipa> for example, anyone on the network who sees the payment message can broadcast the transaction
187 2014-05-09 12:30:49 <sipa> even if the merchant doesn't get it
188 2014-05-09 12:31:18 <hearn> the payment message is only sent to the merchant, so how does that happen?
189 2014-05-09 12:31:28 <jouke> merchant could use https for the payment protocol
190 2014-05-09 12:31:34 <sipa> yes, and he should
191 2014-05-09 12:31:44 <hearn> and i think all of the existing ones do
192 2014-05-09 12:31:44 <sipa> but https isn't the only supported transport
193 2014-05-09 12:32:08 <Grouver> Did anyone already take a look at this? :(   https://github.com/bitcoin/bitcoin/issues/3665
194 2014-05-09 12:32:31 <sipa> basically, when sending a payment message, you must be completely final in your decision that you're ready to send money
195 2014-05-09 12:32:41 <sipa> there is no guaranteed way of cancelling anymore
196 2014-05-09 12:32:46 <jouke> The only usecase I can think of is that the receiver can claim that the transaction was not done in time, but your proposal doesn't really solve that issue I believe?
197 2014-05-09 12:33:11 <jouke> Grouver: I believe I saw a commit on it recently.
198 2014-05-09 12:33:35 <Grouver> jouke, nice. okay.
199 2014-05-09 12:33:47 <sipa> yet the merchant may (for legitimate or illegitimate reasons) not accept the payment
200 2014-05-09 12:34:17 <sipa> this extra step makes sure both parties fully agree on both the payment request and the payment
201 2014-05-09 12:34:26 <sipa> before the actual money has a chance to move
202 2014-05-09 12:34:52 <jouke> But he can still disagree when the scriptsigs are added
203 2014-05-09 12:35:24 <sipa> no, as paymentack + matching confirmed transaction would be a valid payment proof
204 2014-05-09 12:35:37 <sipa> the receiver doesn't care about the scriptsigs
205 2014-05-09 12:35:57 <jouke> The scriptsigs might be unreasonable large?
206 2014-05-09 12:36:11 <sipa> regarding the size they add: good point; it can be avoided by also putting a total max tx size in the payment message
207 2014-05-09 12:36:32 <jouke> True. But what about the time-issue?
208 2014-05-09 12:36:43 <hearn> but the payment is crafted as the merchant requested
209 2014-05-09 12:36:56 <hearn> so the merchant agrees to it by definition, when they formatted the Payment message
210 2014-05-09 12:37:08 <hearn> and by uploading a signed tx that satisfies those outputs, the buyer signals agreement too
211 2014-05-09 12:37:19 <hearn> so i’m still not sure what exact real world scenario this addresses
212 2014-05-09 12:37:35 <hearn> i mean, other payment methods don’t have anything like this AFAICT
213 2014-05-09 12:37:45 <sipa> ... removing the risk that a transaction confirms but the payment isn't accepted
214 2014-05-09 12:38:16 <sipa> + it gives the sender the guarantee that the receiver saw the refund address
215 2014-05-09 12:38:36 <sipa> (or whatever other fields we want to add to the return channel)
216 2014-05-09 12:39:17 <hearn> a confirmed tx that pays the merchants requested outputs is complete and must be accepted, otherwise it’s just plain old fraud. in what circumstance would a tx that pays the outputs the merchant requested, that is confirmed on the block chain, somehow be legitimately unacceptable as payment?
217 2014-05-09 12:39:44 <hearn> the only one i can think of is if the payment came much, much later than requested. but the block chain timestamps things and the payment request has an expiry time in
218 2014-05-09 12:39:50 <sipa> what if the merchant never saw the refund address?
219 2014-05-09 12:39:52 <hearn> so the merchant can say “yes they paid my addresses. but only 3 months later
220 2014-05-09 12:40:14 <hearn> so then an arbiter can say ok the payment is not valid because you didn’t fulfil the terms of the contract. avoiding this is the reason for direct submission anyway.
221 2014-05-09 12:40:37 <hearn> sipa: how does that happen? the Payment is submitted to the merchant via some protocol, we assume that protocol is reliable. e.g. for HTTPS there is a 200 OK or a 400 Bad Request error
222 2014-05-09 12:40:40 <sipa> i know, but gavin doesn't want to require direct submission
223 2014-05-09 12:40:50 <jouke> which is optional in android wallet btw
224 2014-05-09 12:40:54 <jouke> exactly.
225 2014-05-09 12:41:16 <hearn> it’s not intended to remain optional, actually
226 2014-05-09 12:41:30 <hearn> andreas just didn’t take it out yet - it’s a holdover from reusing code written for bluetooth back when that was experimental
227 2014-05-09 12:41:48 <hearn> but yes this is why i argued for direct submission only and it’s what i think most wallets are implementing.
228 2014-05-09 12:41:55 <jouke> We consider a refund address a realy realy nice feature to have, but you have to take into consideration that  the direct submission may fail, but the actual transaction might reach the p2p network
229 2014-05-09 12:41:59 <hearn> it solves a lot of problems
230 2014-05-09 12:42:11 <sipa> jouke: yes, that is my problem: the backchannel is not reliable
231 2014-05-09 12:42:13 <hearn> well, if a wallet doesn’t broadcast it, then it can’t reach the p2p network
232 2014-05-09 12:42:20 <hearn> so there is only the backchannel and that problem doesn’t happen
233 2014-05-09 12:42:32 <jouke> I would prefer direct submission only as well
234 2014-05-09 12:42:44 <sipa> hearn: gavin wanted support for using one transaction for multiple payments
235 2014-05-09 12:43:03 <sipa> hearn: which is incompatible with that, as one merchant may broadcast before the others have agreed
236 2014-05-09 12:43:16 <jouke> Ah. didn't think of that usecase.
237 2014-05-09 12:43:18 <jouke> Makes sense.
238 2014-05-09 12:43:19 <hearn> yeah. i think we’re not going to be able to have that feature. it’s not compatible with other things
239 2014-05-09 12:43:29 <sipa> it is compatible with my proposal
240 2014-05-09 12:43:48 <jouke> hearn: maybe wallets like coinbase might use it?
241 2014-05-09 12:44:37 <sipa> i'm not sure that use case is a priority, but it was part of gavin's reasoning against requiring direct submission
242 2014-05-09 12:44:55 <hearn> people already complain massively about the huge delays coinbase puts on transactions, so i hope they would not do that
243 2014-05-09 12:45:01 <sipa> requiring direct submission would remove part of my concerns with the reliability of the backchannel, but not as waterproof as my proposal
244 2014-05-09 12:45:46 <hearn> i’m not sure what you’re proposing changes anything. with direct submission, you provide a Payment message. if you get back 200 OK it means the merchant saw everything in the message, understood it and is fine with it.
245 2014-05-09 12:45:54 <hearn> their broadcast of the tx indicates acceptance
246 2014-05-09 12:46:45 <hearn> but if at some point there is something where merchants might legitimately want to reject based on the contents of a Payment message then yes, we could add another round
247 2014-05-09 12:46:58 <hearn> at the moment i’m not sure there is. transactions that violate the IsStandard rules, perhaps?
248 2014-05-09 12:47:23 <hearn> but then they can just refuse the Payment message. if they take the money anyway, back to square one - they might have returned 400 Bad Request but they took the money, so the sale is final
249 2014-05-09 12:47:33 <sipa> they can still broadcast without giving you an ack (=proof of payment), they may disagree that that transaction will confirm in reasonable time, their clock may be off and the address may have expired, they may change the refund address in your payment to something of their own and do a refund a later claim that the transaction was succesfully refunded, ...
250 2014-05-09 12:47:45 <hearn> the ACK is not the proof of payment
251 2014-05-09 12:47:52 <hearn> ACK is not signed so it proves nothing, by itself. it’s not auditable.
252 2014-05-09 12:47:53 <sipa> ACK + transaction is proof of payment
253 2014-05-09 12:48:01 <hearn> no. PaymentRequest + transaction is proof of payment
254 2014-05-09 12:48:11 <hearn> it’s the PaymentRequest that’s signed. everything else is forgeable.
255 2014-05-09 12:48:16 <sipa> what?
256 2014-05-09 12:48:19 <sipa> seriously?
257 2014-05-09 12:48:29 <hearn> huh? you did read BIP 70, right?
258 2014-05-09 12:48:35 <hearn> are we talking about the same protocol? :)
259 2014-05-09 12:49:03 <jouke> A signed refund-address might be a nice feature
260 2014-05-09 12:49:14 <sipa> ok, i hereby retract my proposal
261 2014-05-09 12:49:21 <sipa> it's pointless if the ack isn't signed
262 2014-05-09 12:49:23 <hearn> yeah. we talked about that at the time. but we wanted to simplify and ship
263 2014-05-09 12:49:44 <hearn> you’d have to sign the Payment with a key from the transaction, as well, so you end up in a mess with different kinds of script types and stuff like that
264 2014-05-09 12:49:44 <sipa> but it makes the entire backchannel feature very unreliable imho
265 2014-05-09 12:50:04 <jouke> With all the bitcoin pkscripts changing mallware.
266 2014-05-09 12:50:29 <hearn> yeah. again we did discuss this, i remember talking about it with gavin. i don’t recall where exactly.
267 2014-05-09 12:50:56 <sipa> i very much dislike requiring signatures using the payment tx key
268 2014-05-09 12:51:00 <sipa> it breaks the transparency
269 2014-05-09 12:51:01 <hearn> we decided, if MITM changing refund addresses starts to become a problem, we can bite the bullet and define ways to make scriptSigs to keys that can be used to sign the Payment message
270 2014-05-09 12:51:05 <hearn> yeah
271 2014-05-09 12:51:14 <sipa> plus it means the sender and payer have to be the same entity
272 2014-05-09 12:51:15 <hearn> the problem is, most users don’t have any kind of other key that is meaningful.
273 2014-05-09 12:51:21 <sipa> there's no need
274 2014-05-09 12:51:24 <hearn> so that’s another reason we didn’t tackle it in v1
275 2014-05-09 12:51:30 <sipa> a signed ack + my proposal would make it safe regardless
276 2014-05-09 12:51:47 <sipa> if the signed ack doesn't contain the correct refund address, you don't pay
277 2014-05-09 12:52:13 <hearn> yes, that also works. i’m not sure how well it plays with the async store-and-forward use case where the recipient may be offline at the time you’re trying to pay them though
278 2014-05-09 12:52:32 <sipa> yeah, you want some delegation i guess
279 2014-05-09 12:52:34 <hearn> the nice thing about the current protocol is, you can craft a long term PaymentRequest and then just let Payment messages stream in. the ACK is sort of just a convenience, it’s not realy essential
280 2014-05-09 12:52:40 <sipa> where the ack may be signed by a different key than the request
281 2014-05-09 12:53:02 <sipa> the ack is a way to know the backchannel worked
282 2014-05-09 12:53:50 <hearn> well, *today* it’s just a convenience. the assumption is that the protocol runs over some other protocol that provides request/response semantics, like http.
283 2014-05-09 12:54:08 <hearn> so it’s possible for a Payment to be rejected/accepted at a lower level
284 2014-05-09 12:54:14 <hearn> but it may at some point make sense to change it yes
285 2014-05-09 12:54:18 <sipa> anyway
286 2014-05-09 12:54:24 <sipa> it's not a proposal for today
287 2014-05-09 12:54:31 <sipa> but i'd very much like to see it in a v2 :)
288 2014-05-09 12:55:03 <hearn> heh ok :) i’m hoping we won’t need a backwards incompatible version for a long time. though it may be useful to have an optionally backwards incompatible version if a wallet wants to force the usage of new features, rather than getting paid in a worse way.
289 2014-05-09 12:55:13 <hearn> but a v1.1 or v1.2 or whatever, sure
290 2014-05-09 12:55:18 <hearn> hi there gavinandresen
291 2014-05-09 12:55:24 <gavinandresen> howdy
292 2014-05-09 13:34:18 <maraoz> would it make sense to have blocks that reference more than one hashPrevBlock, if those pointed to non-conflicting forks?
293 2014-05-09 13:36:21 <maraoz> that way we could have part of the network mining on some fork, and then merge the branches later into the "main blockchain", as long as there's no conflicting transactions (i.e only different outputs were spent on the branch)
294 2014-05-09 13:40:05 <wumpus> howdy
295 2014-05-09 13:40:37 <wumpus> warren: I'm going to split off the 0.9.2 branch now
296 2014-05-09 13:41:53 <venzen> wumpus, when is the official release date for 0.9.2?
297 2014-05-09 13:42:08 <survic> maraoz: that wouldn't achieve much. stale chains have their transactions returned to the memory pool.
298 2014-05-09 13:44:18 <wumpus> venzen: the plan is to release rc1 the 13th, but as you know, no guarantees, it's done when it's done
299 2014-05-09 13:45:19 <venzen> wumpus: thanks, i won't publish until it's confirmed here
300 2014-05-09 13:46:50 <venzen> wumpus: in fact, i prefer to publish after the signing and official announcement so that the facts are straight
301 2014-05-09 13:54:33 <wumpus> venzen: great
302 2014-05-09 14:03:06 <maraoz> survic: if branches were allowed to be mined (without reward) at a much lower difficulty, you could have local forks of the blockchain to deal with local transactions
303 2014-05-09 14:05:17 <survic> maraoz: that's not a good idea, just reaching convergence might never happen, then you're stuck with a dinky side chain that's stale. not worth forking the chain for that anyway.
304 2014-05-09 14:05:28 <Luke-Jr> maraoz: with no value to the forks..
305 2014-05-09 14:05:35 <Luke-Jr> what survic said :P
306 2014-05-09 14:07:39 <maraoz> Luke-Jr, survic: ok let me think about it better :)
307 2014-05-09 14:31:38 <CodeShark> sidechains with lower difficulty and lower rewards that could still be used for total difficulty calculation could work (i.e. GHOST and its derivatives)
308 2014-05-09 14:32:34 <survic> if there's lower reward nobody will mine them.
309 2014-05-09 14:33:00 <coryfields> wumpus: ping
310 2014-05-09 14:33:05 <CodeShark> huh? you mine for the higher difficulty - but if you happen to stumble upon a lower difficulty share, you could still submit it
311 2014-05-09 14:33:31 <survic> so, merge mining?
312 2014-05-09 14:33:38 <CodeShark> sorta
313 2014-05-09 14:33:47 <coryfields> wumpus: the deterministic build is ready, i'm going to spend a few hours today getting it all shoved into gitian descriptors. Thing is, it's going to be kinda unruly
314 2014-05-09 14:33:56 <coryfields> curious to hear your thoughts.
315 2014-05-09 14:34:04 <Luke-Jr> unruly?
316 2014-05-09 14:34:12 <CodeShark> it's not exactly merge mining because in merge mining you're dealing with separate chains entirely
317 2014-05-09 14:34:27 <survic> you can't mine on two heads at once though
318 2014-05-09 14:34:29 <coryfields> I'm not sure how I'd like it to look once it's all cleaned up. But for .9.2, about all I can do is shove it all into a handful of descriptors
319 2014-05-09 14:35:13 <survic> at least not with our current header system. I don't see that changing given the amount of software built into hardware with it.
320 2014-05-09 14:35:59 <coryfields> Luke-Jr: I wanted to have some cleaner approach before PRing it upstream. But if it's going to make it into the next release, I don't really have time for that. It'll be pretty rough to review.
321 2014-05-09 14:36:29 <sipa> CodeShark: like the p2pool sharechain?
322 2014-05-09 14:36:40 <CodeShark> sipa - yeah, something similar, perhaps
323 2014-05-09 14:38:36 <coryfields> anyway, I'm going to go ahead and start shoving it into some descriptors. If you guys find it too ugly, we can push back to a later release
324 2014-05-09 14:39:57 <Luke-Jr> coryfields: I thought this was all done months ago? :/
325 2014-05-09 14:40:44 <coryfields> Luke-Jr: it was done, yea, but there were a few TODOs, and some things have changed since
326 2014-05-09 14:41:15 <coryfields> Luke-Jr: it now uses qt5, shares the source deps with win32, dmg compression is enabled, etc
327 2014-05-09 14:41:44 <coryfields> so i'm pushing for mainline inclusion this time around
328 2014-05-09 14:42:15 <Luke-Jr> ah
329 2014-05-09 14:42:37 <Luke-Jr> good ideas ☺
330 2014-05-09 14:43:39 <coryfields> compression took it from ~57mb to ~18 :)
331 2014-05-09 15:12:03 <wumpus> coryfields: poing
332 2014-05-09 15:12:33 <wumpus> coryfields: as long as there are clear instructions, it doesn't matter if it's going to be a bit unruly
333 2014-05-09 15:12:46 <wumpus> coryfields: let's just get it to work! :)
334 2014-05-09 15:14:05 <wumpus> coryfields: and anyway as the current way of building mac releases sucks completely, it can only improve
335 2014-05-09 15:14:40 <coryfields> ok
336 2014-05-09 15:14:48 <coryfields> will try to get the PR up today
337 2014-05-09 15:15:17 <coryfields> just be sure to give more weight to the result than the process ;)
338 2014-05-09 15:18:43 <coryfields> also, my macbook died (again) yesterday. So I'm kinda flying blind until next week
339 2014-05-09 15:18:56 <coryfields> I can get it up long enough to verify that bitcoin-qt runs, but that's about it
340 2014-05-09 15:27:33 <wumpus> I cannot verify the macosx builds either, but there are enough people that can, building for mac is the hard part
341 2014-05-09 15:41:30 <wumpus> can anyone help with upgrading leveldb to 1.17? I always mess up subtree merges, ending up scattering files all through the tree
342 2014-05-09 15:43:00 <sipa> wumpus: willdo
343 2014-05-09 15:43:23 <wumpus> sipa: thanks
344 2014-05-09 15:46:20 <michagogo> cloud|wumpus: you could always just back up the bitcoin/ dir :P
345 2014-05-09 16:08:17 <hearn> wumpus: yeah i found subtrees to be confusing. rebases seem to kill them too
346 2014-05-09 16:08:32 <sipa> rebases always kill merges
347 2014-05-09 16:08:46 <sipa> but agree, they're confusing
348 2014-05-09 16:09:34 <sipa> anyway, pushed a 1.17 version to the bitcoin/leveldb repo
349 2014-05-09 16:09:44 <sipa> now running the leveldb unit tests on it
350 2014-05-09 16:09:49 <sipa> afterwards i'll pullreq
351 2014-05-09 16:14:03 <sipa> wumpus: do we want to revert the .sst/.ldb switch?
352 2014-05-09 16:14:56 <sipa> wumpus: summary: leveldb 1.14 or so changed the default extension for writing to .ldb instead of the .sst that older versions used; this broke bitcoind's downgrading functionality (as older bitcoind with older leveldb didn't read .ldb at all)
353 2014-05-09 16:15:18 <sipa> wumpus: since then 0.9 has been released, and presumably 0.10 will break backward compatibility again
354 2014-05-09 16:16:19 <hearn> did the name change cooincide with a format change?
355 2014-05-09 16:16:43 <sipa> at the leveldb side? no
356 2014-05-09 16:16:50 <hearn> seems like a dick move for them to change the name like that but not the format
357 2014-05-09 16:16:50 <wumpus> sipa: I think it makes sense to keep that
358 2014-05-09 16:17:00 <sipa> but 0.9 broke backward compatibility anyway
359 2014-05-09 16:17:08 <sipa> and 0.10 will presumably do so again
360 2014-05-09 16:17:17 <sipa> wumpus: which? write to .ldb or to .sst?
361 2014-05-09 16:17:21 <wumpus> that's true
362 2014-05-09 16:17:27 <sipa> i prefer staying as close as possible to upstream
363 2014-05-09 16:17:54 <hearn> why do you say it’ll do so again?
364 2014-05-09 16:17:56 <wumpus> okay, but I suppose we also want the leveldb upgrade for 0.9.2, and I think it's counter-intuitive to change such a thing in a minor version
365 2014-05-09 16:17:57 <hearn> because of headers first?
366 2014-05-09 16:18:06 <sipa> yes
367 2014-05-09 16:18:21 <sipa> wumpus: 0.9 uses modern leveldb, so there is no problem
368 2014-05-09 16:18:34 <wumpus> ok
369 2014-05-09 16:18:35 <sipa> 0.9's leveldb reads both .sst and .ldb, but writes to .sst
370 2014-05-09 16:18:37 <hearn> ah
371 2014-05-09 16:18:38 <hearn> i see
372 2014-05-09 16:18:47 <hearn> seems better to just keep the upstream behaviour then
373 2014-05-09 16:19:08 <wumpus> yes, let's switch to upstream behaviour then
374 2014-05-09 16:19:12 <sipa> we temporarily swapped .sst and .ldb for a few versions to retain backwards compatibility, but forward is never a problem
375 2014-05-09 16:19:15 <sipa> oki!
376 2014-05-09 16:29:50 <gmaxwell> hearn: the prior name was causing windows system restore to corrupt the database.
377 2014-05-09 16:30:01 <hearn> huh!
378 2014-05-09 16:30:07 <hearn> that’s ……
379 2014-05-09 16:30:12 <hearn> i can’t think of an adjective
380 2014-05-09 16:30:27 <hearn> i guess sst == System reSTore point or somehing
381 2014-05-09 16:30:50 <sipa> yes! but .ldb conflicts with the LogDB file format i once wrote as replacement for wallet.dat!
382 2014-05-09 16:31:08 <hearn> so far my personal file extension is safe.
383 2014-05-09 16:31:11 <hearn> nobody elses uses .sux
384 2014-05-09 16:32:52 <gmaxwell> hearn: we've also recently had a rash of complaints about windows AV software corrupting nodes because of 16 byte malware signatures in the chainstate. Amusingly, we've had testcases in testnet forever, but they were in the blocks not the chainstate, and apparently most (all?) av software ignores files over 32mbytes.
385 2014-05-09 16:33:46 <hearn> i wonder how easy it is to adjust the file size leveldb uses.
386 2014-05-09 16:34:51 <gmaxwell> it doesn't looke like leveldb preallocates— some of the files are smaller than the normal size.
387 2014-05-09 16:36:28 <hearn> i think mmap on some systems might have once done that
388 2014-05-09 16:36:33 <hearn> don’t recall
389 2014-05-09 16:36:46 <hearn> right. home time.
390 2014-05-09 16:36:53 <sipa> they only use mmap for reading, afaik
391 2014-05-09 16:37:23 <posita> @hearn: see http://forums.anandtech.com/showthread.php?t=2250551 (re: .sux; NSFW)
392 2014-05-09 16:37:45 <posita> (Off topic, by the way.)
393 2014-05-09 16:37:49 <gmaxwell> In any case, the av false positives can be more reliably surpressed by obfuscating the data.
394 2014-05-09 16:37:58 <hearn> yes indeed
395 2014-05-09 17:21:14 <zone117x> sipa you there?
396 2014-05-09 17:21:21 <zone117x> having troubles getting testnet to stay local
397 2014-05-09 17:21:31 <zone117x> using listen=0 in conf for main daemon
398 2014-05-09 17:21:49 <zone117x> then connect=127.0.0.1 in second daemon
399 2014-05-09 17:22:07 <zone117x> but as soon as I start first deamon it starts connecting to global testnet
400 2014-05-09 17:22:16 <zone117x> ignoring the listen=0 it seems
401 2014-05-09 17:22:38 <survic> that's normal behaviour
402 2014-05-09 17:22:40 <maraoz> are bloom filters already implemented and used in bitcoind?
403 2014-05-09 17:22:55 <survic> maraoz: yes.
404 2014-05-09 17:23:18 <survic> bitcoind itself doesn't use them, but it can supply them on request of a peer
405 2014-05-09 17:23:21 <sipa> -listen=0 doesn't prevent outgoing connections
406 2014-05-09 17:23:28 <sipa> i told you to pass -connect=0.0.0.0
407 2014-05-09 17:23:41 <sipa> (or was that someone else, sorry)
408 2014-05-09 17:24:08 <zone117x> alright so for both local daemons just use -connect to each others ports?
409 2014-05-09 17:24:14 <maraoz> survic: thanks, that was exactly what I needed to know
410 2014-05-09 17:24:43 <sipa> zone117x: no
411 2014-05-09 17:24:46 <survic> maraoz: bitcoinj/multubit uses them as does another SPV client if you want examples
412 2014-05-09 17:25:02 <sipa> zone117x: one uses -connect=otherip, the other uses -connect=0.0.0.0 -listen=1
413 2014-05-09 17:25:31 <zone117x> alright which one to start first, or does that not matter?
414 2014-05-09 17:25:39 <sipa> which do you think?
415 2014-05-09 17:26:10 <zone117x> :/ the second one, just making sure
416 2014-05-09 17:26:21 <sipa> yup
417 2014-05-09 17:26:27 <sipa> not that it actually matters
418 2014-05-09 17:26:33 <sipa> but it helps to understand what you're doing
419 2014-05-09 17:27:20 <zone117x> haha I hope I know what I'm doing - I'm dev of NOMP https://github.com/zone117x/node-open-mining-portal
420 2014-05-09 17:27:55 <maraoz> survic: gotcha. I'm interested in understanding how bitcoind provides the "bloom filter service" for now. I'll read the code thanks
421 2014-05-09 17:28:10 <sipa> maraoz: read BIP 37
422 2014-05-09 17:31:32 <alumn> hello
423 2014-05-09 17:31:34 <alumn> in bitcoind
424 2014-05-09 17:31:40 <alumn> is there a way to verify a transaction hex?
425 2014-05-09 17:32:09 <alumn> for example, if a hex is incorrect and you use ‘sendrawtransaction’ it will be rejected and if it is correct it will be sent
426 2014-05-09 17:32:20 <alumn> is there a way to check if the hex is correct without sending it?
427 2014-05-09 17:32:47 <survic> decoderawtransaction might give errors, not sure.
428 2014-05-09 17:32:57 <sipa> it will give decoding errors
429 2014-05-09 17:33:02 <alumn> it will give decoding error
430 2014-05-09 17:33:09 <alumn> but if let’s say a signature is incorrect
431 2014-05-09 17:33:18 <alumn> or contains a double spend
432 2014-05-09 17:33:20 <sipa> i don't think there's a full way to check validity without broadcasting
433 2014-05-09 17:33:22 <alumn> I see
434 2014-05-09 17:33:25 <sipa> maybe submit a feature request?
435 2014-05-09 17:33:31 <alumn> where should I do that?
436 2014-05-09 17:33:37 <alumn> on github?
437 2014-05-09 17:34:01 <chichov> could anyone point out some resources explaining the bitcoin networking code?
438 2014-05-09 17:34:01 <sipa> github.com/bitcoin/bitcoin/issues yes
439 2014-05-09 17:34:21 <sipa> chichov: the only resource explaining the network _code_ is the code i'm afraid
440 2014-05-09 17:34:35 <sipa> there may be documents that explain part of the networking protocol though
441 2014-05-09 17:34:36 <chichov> sipa: I already feared that
442 2014-05-09 17:34:58 <chichov> that might be helpful, do you have any links on that?
443 2014-05-09 17:36:19 <sipa> chichov: https://bitcointalk.org/index.php?topic=41718.0
444 2014-05-09 17:36:27 <chichov> I also have another question - if I create a raw transaction object (CTx), how can I pass it to be sent over the network?
445 2014-05-09 17:36:27 <sipa> may be outdated, though
446 2014-05-09 17:36:47 <sipa> sendrawtransaction ?
447 2014-05-09 17:37:03 <chichov> sounds like what I'm looking for, I'll dig into that
448 2014-05-09 17:37:36 <sipa> if you mean via P2P, you'd first broadcast an inv message to announce the transaction's existence, and then answer getdata requests for it using 'tx' messages with the full transaction
449 2014-05-09 17:37:46 <sipa> ugh, that document is indeed very outdated
450 2014-05-09 17:37:52 <sipa> it mentioned IRC discovery :)
451 2014-05-09 17:38:33 <chichov> what's an "inv" message?
452 2014-05-09 17:39:00 <sipa> https://en.bitcoin.it/wiki/Protocol_specification#inv
453 2014-05-09 17:40:17 <chichov> alright, so if I plan on sending a Tx via P2P then I first have to announce the existence of the message (via message) and then other nodes will request it for me?
454 2014-05-09 17:40:48 <sipa> yes
455 2014-05-09 17:40:58 <chichov> alright, thanks for the help
456 2014-05-09 17:41:10 <chichov> I'll read the wiki + code and try to put the pieces together then
457 2014-05-09 17:43:41 <Einewton> chichov, I've been going throguh that stuff myself over the last few months going back throgh older clients and comparting with new code to really understand the changes... It's a journey for sure.
458 2014-05-09 17:47:38 <sipa> Hmm, which rules in BIP62 could be made outright illegal in a softfork?
459 2014-05-09 17:47:47 <sipa> 2, 4, 5, 6 for sure.
460 2014-05-09 17:48:17 <sipa> 1 requires a modification to wallets that isn't currently widely deployed, so probably not.
461 2014-05-09 17:49:16 <sipa> 3 and 7... may in theory restrict the usefulness of the script languages
462 2014-05-09 17:49:57 <sipa> so i'd say 2,4,5,6 can be made non-standard immediately, and illegal in a softfork
463 2014-05-09 17:50:05 <gmaxwell> 1 ought to be measured, I've been prodding people to fix their signing code, it might be interesting to see how much further we have to go.
464 2014-05-09 17:50:14 <sipa> 1,3,7 are only enforced in v3 transactions
465 2014-05-09 17:50:17 <gmaxwell> (I don't think it could be done immediately, of course)
466 2014-05-09 17:50:50 <gmaxwell> before we do anything with transaction versions we need to uncorrupt the chainstates.
467 2014-05-09 17:51:05 <sipa> i mostly want rule #2 as a softfork, so we can use non-OpenSSL signature parsing...
468 2014-05-09 17:51:30 <gmaxwell> Ah.
469 2014-05-09 17:51:33 <sipa> idea: make the chainstate store the *effective* transaction version
470 2014-05-09 17:53:55 <sipa> on the other hand, there could be a GetTxVersion on CCoins, which compares the height with flipover heights, and cramp the result
471 2014-05-09 18:02:20 <maaku> sipa: or do both
472 2014-05-09 18:11:47 <coryfields> sipa: are the bignum tests still needed just to be doubly sure that we don't deviate from any accidental legacy behavior?
473 2014-05-09 18:12:36 <sipa> coryfields: well, i want some tests on scriptnum behaviour - whether they're based on bignum or not
474 2014-05-09 18:12:43 <coryfields> i assumed the scriptnum checks would switch to using uint256.h or so for those checks
475 2014-05-09 18:13:02 <sipa> uint256.h doesn't have signs or the getvch encoding
476 2014-05-09 18:13:23 <sipa> so what you're left testing would really just be int64_t semantics
477 2014-05-09 18:13:31 <coryfields> hmm, right
478 2014-05-09 18:13:40 <sipa> i think we'll want some data driven tests
479 2014-05-09 18:13:55 <sipa> just a bunch of numbers, their operations, and known getvch and getint results for them
480 2014-05-09 18:14:38 <sipa> i should have considered the deprecation of bignum.h when i suggested writing bignum-based tests
481 2014-05-09 18:14:41 <coryfields> yea, agreed
482 2014-05-09 18:14:53 <coryfields> well, it was necessary for sure
483 2014-05-09 18:14:59 <SoftwareMechanic> If I'm developing a client, does it make sense to have someone recognized as a bitcoin expert "validate" it?
484 2014-05-09 18:15:38 <coryfields> i can adapt the tests to hard-code the data pretty easily, i think. There are 2 arrays in scriptnum_tests that attempt to hit the most interesting values
485 2014-05-09 18:15:41 <sipa> so: what type of client?
486 2014-05-09 18:15:58 <sipa> SoftwareMechanic:
487 2014-05-09 18:16:07 <SoftwareMechanic> Either a hardware wallet or a pc-based wallet
488 2014-05-09 18:16:18 <sipa> SPV?
489 2014-05-09 18:16:20 <SoftwareMechanic> It would be a proprietary closed-source product
490 2014-05-09 18:16:50 <sipa> then go ask elsewhere
491 2014-05-09 18:17:01 <SoftwareMechanic> ok
492 2014-05-09 18:17:36 <sipa> coryfields: that'd be cool
493 2014-05-09 18:17:55 <coryfields> sipa: ok, adding to my list
494 2014-05-09 18:18:01 <gmaxwell> SoftwareMechanic: most people will strongly recommend no one use your software. Its simply too easy to embed kleptographic features in a closed source program.
495 2014-05-09 18:18:23 <SoftwareMechanic> gmaxwell: ya, that's my concern as well
496 2014-05-09 18:19:16 <SoftwareMechanic> It's kind of a strange area.  You want to encourage people to develop new bitcoin products, but they usually want close source to maintain some business advantage
497 2014-05-09 18:19:30 <MCM-Mike> into which channel is my bitcoind node connected on "irc://pelican.heliacal.net" ?
498 2014-05-09 18:19:33 <sipa> so: charge for support or serviced features
499 2014-05-09 18:19:35 <maaku> SoftwareMechanic: there is no reason to close-source the relevant parts of the wallet
500 2014-05-09 18:19:40 <sipa> SoftwareMechanic: charge for support or serviced features
501 2014-05-09 18:20:03 <sipa> MCM-Mike: irc bootstrapping was removed in bitcoin 0.6
502 2014-05-09 18:20:26 <MCM-Mike> I know but it seems that my node is still connecting to this irc server
503 2014-05-09 18:20:52 <sipa> what node are you running?
504 2014-05-09 18:20:58 <sipa> what software?
505 2014-05-09 18:22:05 <MCM-Mike> sorry ma bad, was an old netstat output I was looking at
506 2014-05-09 18:23:16 <SoftwareMechanic> Say the essential parts of the software for a hardware wallet was to be open sourced, seems like it would make sense to have it reviewed before releasing it.
507 2014-05-09 18:24:36 <SoftwareMechanic> What's the best route to go to get it reviewed?
508 2014-05-09 18:25:48 <sipa> open source it
509 2014-05-09 18:29:06 <SoftwareMechanic> I don't know, I'd like to have it at least vetted by and second person first.
510 2014-05-09 18:29:22 <SoftwareMechanic> I'm accustomed to Independent verification for critical systems
511 2014-05-09 18:29:28 <SoftwareMechanic> Maybe I'm missing something
512 2014-05-09 18:30:00 <SoftwareMechanic> Could also be I haven't had enough coffee today yet
513 2014-05-09 18:30:11 <sipa> well, if you find someone who's willing to review it, go ahead
514 2014-05-09 18:30:22 <midnightmagic> SoftwareMechanic: If nobody is using it, then there is no risk of anything being lost. Open source it, and either the vetting happens (because of interest or you paid someone), or it doesn't, because nobody likes the product and thinks it's a bad idea.
515 2014-05-09 18:30:26 <sipa> but i doubt you'll find anyone here interested in reviewing things that aren't open source
516 2014-05-09 18:37:57 <SoftwareMechanic> So here's the dilemma, say you have a Trezor like device and you want to sell N units.  Obviously you want the firmware well reviewed and vetted before you sell those units.  Open sourcing it is a step on that path, but doesn't get you all the way there.
517 2014-05-09 18:38:40 <SoftwareMechanic> Obviously you start small, but you want to make sure you have a product before you start cranking out units.  Trezor didn't release their firmware on day 1.  It took them awhile.
518 2014-05-09 18:38:54 <SoftwareMechanic> I'm presuming they had folks look at it.
519 2014-05-09 18:39:46 <gmaxwell> Releasing the firmware for something like that isn't really sufficient. Instead something like the trezor can be designed so that it has no side channel from which to screw you.
520 2014-05-09 18:41:00 <SoftwareMechanic> I don't think they've open sourced their schematics and layout.
521 2014-05-09 18:42:12 <SoftwareMechanic> How would you make a determination that there is no side channel?  I suppose you could pop it open and inspect it, download the flash and verify the dissassembly.
522 2014-05-09 18:43:53 <gmaxwell> SoftwareMechanic: because you can use a signature process which is completely determinstic, so there is no place for the signer to add extra data. If there were a sidechannel it would have to be very infrequent to have a chance of not being easily detectable.
523 2014-05-09 18:44:42 <survic> ideally the Trezor would be 100% deterministic and just supply dice and a lookup table
524 2014-05-09 18:44:56 <survic> no RNG, no messing around
525 2014-05-09 18:51:57 <robonerd> is the correct case for mentioning bitcoin in documentation "Bitcoin" or "bitcoin"
526 2014-05-09 18:52:41 <sipa> Bitcoin the system, bitcoin the currency.
527 2014-05-09 18:52:55 <robonerd> what's the difference please?
528 2014-05-09 18:55:19 <SoftwareMechanic> gmaxwell: ya, that is true.  I was thinking you meant side channel as providing a rogue bootloader or something.
529 2014-05-09 18:57:55 <sipa> robonerd:
530 2014-05-09 18:58:06 <sipa> * I downloaded the Bitcoin reference client.
531 2014-05-09 18:58:14 <sipa> * This system uses the Bitcoin protocol.
532 2014-05-09 18:58:23 <sipa> * The Bitcoin network is growing every day.
533 2014-05-09 18:58:30 <sipa> * I paid him 0.5 bitcoin.
534 2014-05-09 18:58:45 <SoftwareMechanic> gmaxwell:  Why do you say that releasing the software/firmware would not be sufficient?
535 2014-05-09 18:58:47 <robonerd> why is there a difference?
536 2014-05-09 18:58:58 <dabura667> Quick question for anyone who can answer, can you "break off" branches of an HD BIP 32 wallet seed? ie store master seed in safe, store master private key of ONLY branch 1 on one device, 2 on another device, and master public of ONLY branch 1 on this, 2 on that... etc.?
537 2014-05-09 18:59:00 <sipa> robonerd: because we don't capitalize "dollar" either
538 2014-05-09 18:59:14 <SoftwareMechanic> bitcoin is a currency, Bitcoin is a proper noun referring to the system and protocol
539 2014-05-09 18:59:30 <survic> SoftwareMechanic: how do you know your device is running it?
540 2014-05-09 18:59:49 <sipa> I'm unsure about "the Bitcoin economy is growing" or "the bitcoin economy is growing"
541 2014-05-09 19:00:01 <SoftwareMechanic> You have a bootloader running in a locked flash section that reports it's checksum at boot.
542 2014-05-09 19:00:18 <sipa> dabura667: i don't understand the question
543 2014-05-09 19:00:18 <SoftwareMechanic> It's about as good as you can get without flashing the device yourself with a JTAG
544 2014-05-09 19:00:46 <survic> SoftwareMechanic: that's just it. how do you know if the bootloader is genuine? difficult.
545 2014-05-09 19:01:05 <SoftwareMechanic> It is.  it's a fundamental issue with hardware wallets I think
546 2014-05-09 19:02:02 <survic> they're ultimately trust based
547 2014-05-09 19:02:06 <dabura667> what I mean is. The benefit of HD wallets is being able to restore everything from one seed, your master private key, then derive branches from it.
548 2014-05-09 19:02:14 <SoftwareMechanic> There is always an element of trust of the factory.  Same way you trust that your hard drive vendor isn't stealing your keys.
549 2014-05-09 19:02:17 <sipa> dabura667: if you only plan to use keys from a particular subtree/branch, you only need the private root of that subtree.
550 2014-05-09 19:02:28 <dabura667> The advantage to P2SH multisig is being able to keep private keys separately safe.
551 2014-05-09 19:02:37 <dabura667> ok
552 2014-05-09 19:02:44 <dabura667> so it's possible then, thank you.
553 2014-05-09 19:03:00 <gmaxwell> SoftwareMechanic: I pointed out above that that risk can be substantially elimianted by making the behavior determinstic, so that the device has no side channel.
554 2014-05-09 19:04:33 <dabura667> sipa: my idea was Branch 1, 2, and 3 being used to create sequential 2 of 3 P2SH addresses. Then storing the master private key in a safe place, but on my devices only keep the ability to generate their "1 / 3" of the privkeys.
555 2014-05-09 19:04:40 <dabura667> Thanks for the answer.
556 2014-05-09 19:04:46 <survic> gmaxwell: still not perfect though, it could randomly sign with a k that's known to the author only. just as dangerous because I doubt people would be verifying every single signature.
557 2014-05-09 19:04:56 <sipa> dabura667: i would use completely separate trees
558 2014-05-09 19:05:37 <survic> even if one in every 2048 signatures was backdoored, it would be very hard to detect but very nasty
559 2014-05-09 19:06:04 <dabura667> hmmmmm
560 2014-05-09 19:06:43 <dabura667> so using separate trees obfuscates that type of weakness more than using the same tree would?
561 2014-05-09 19:07:04 <dabura667> oh nvm
562 2014-05-09 19:07:13 <dabura667> different person was talking, I understand
563 2014-05-09 19:07:29 <dabura667> sipa: thanks for your opinion / help
564 2014-05-09 19:09:50 <gmaxwell> survic: Yes, but you have to do that very rarely for it to be unlikely to be caught. Better still can be done: I pushed for devices like trezor to use multisignature, but they said they didn't have time. (which sounded a lot more credible a year ago…)
565 2014-05-09 19:10:29 <SoftwareMechanic> yes, multisig is ideal
566 2014-05-09 19:10:43 <SoftwareMechanic> Kind of what I'm working on actually
567 2014-05-09 19:10:49 <gmaxwell> Blindsigning can be also used to destroy a covert channel, but then having the device approve what its signing is hard.
568 2014-05-09 19:11:10 <SoftwareMechanic> it gets around any backdoor issues with the hardware wallet.