1 2013-07-04 00:04:30 <petertodd> https://bitcointalk.org/index.php?topic=175156.msg2646950#msg2646950 <- lol, Mike's dumping on soft-forks: "There aren't any compelling reasons to use soft forks, IMHO. It is at best controversial."
2 2013-07-04 00:17:31 <nsh> i haven't heard any compelling reasons to use Mike either
3 2013-07-04 00:18:00 <petertodd> He's a bit of a character...
4 2013-07-04 00:18:20 <petertodd> Just technically competent enough that people who don't know better listen to him.
5 2013-07-04 00:18:37 <nsh> ACTION smiles
6 2013-07-04 00:18:58 <nsh> a little learning is a dangerous thing --pope
7 2013-07-04 00:19:12 <nsh> (pope sidious)
8 2013-07-04 00:19:50 <petertodd> Well the problem is partly that Mike focuses on getting things done rather than spending his time thinking, and Bitcoin is new enough that we need thinkers not doers.
9 2013-07-04 00:21:34 <petertodd> John Dillon is kind of the anti-Mike in a way, he never written any code at all, but he obviously understands the system very deeply. The right balance is somewhere in between...
10 2013-07-04 00:25:13 <bombsite> Theory is when one knows everything but nothing works.
11 2013-07-04 00:25:30 <bombsite> Practice is when everything works but nobody knows why.
12 2013-07-04 00:25:47 <bombsite> In our lab, theory and practice go hand in hand: nothing works and nobody knows why.
13 2013-07-04 00:26:06 <IanCormac> lol
14 2013-07-04 00:26:38 <petertodd> It's not that simple... My day job is in electrical engineering, and I regularly do projects where months of paper analysis is followed by a quick implementation of a system that works nearly 100% the first try.
15 2013-07-04 00:27:10 <bombsite> I'm jealous
16 2013-07-04 00:27:12 <petertodd> Theory applied correctly is a lot more valuable than people give it credit for.
17 2013-07-04 00:27:24 <bombsite> I had so much difficulty in my circuits classes
18 2013-07-04 00:27:27 <bombsite> because nothing ever worked
19 2013-07-04 00:27:37 <petertodd> You didn't understand the theory well enough.
20 2013-07-04 00:27:49 <petertodd> Don't mean to be blunt, but that's just the truth of it.
21 2013-07-04 00:28:01 <bombsite> sadly, the theory was like "this is a resistor", "a capacitor stores charge"
22 2013-07-04 00:28:13 <petertodd> Well... they weren't teaching you much theory. :)
23 2013-07-04 00:28:29 <bombsite> it's okay though
24 2013-07-04 00:28:32 <bombsite> I'm just bad :P
25 2013-07-04 00:28:48 <bombsite> they got wrecked trying to design things like theremins
26 2013-07-04 00:28:49 <bombsite> once we broke off and my EE friends started doing their advanced classes
27 2013-07-04 00:29:53 <petertodd> I mean, I work in analog electronics too, a field that is often written off as black magic, and I still manage to apply theory correctly to all sorts of things people write off as black magic and get consistent results. Nothing special about me either, lots of people achieve that.
28 2013-07-04 00:30:20 <petertodd> Ah, what field are you in?
29 2013-07-04 00:33:47 <nsh> petertodd, why haven't memristers given me a hoverboard yet?
30 2013-07-04 00:34:14 <nsh> i thought they were the missing link in electronic components and set to make all sorts of things shiny and new
31 2013-07-04 00:34:17 <petertodd> nsh: They told me it was because you didn't say "please"
32 2013-07-04 00:34:24 <nsh> oh dear :/
33 2013-07-04 00:34:34 <nsh> i hope i haven't been holding up the entire consumer electronics industry again
34 2013-07-04 00:35:17 <IanCormac> Damn it nsh
35 2013-07-04 00:35:28 <petertodd> nsh: Nah, only if someone actually makes working memristors. In fact, the way the press is talking about it is all wrong: memristors are a neat bit of math, and the advance is that researchers came up with these cool electronic components with useful applications that *happen* to be possible to model as memristors.
36 2013-07-04 00:36:02 <nsh> right
37 2013-07-04 00:36:13 <petertodd> In fact, the "revolutionize the industry" memristors people have been talking about are actually not very much like the math models; they match the models even worse than real inductors do.
38 2013-07-04 00:36:20 <nsh> i see
39 2013-07-04 00:36:39 <nsh> my vague recollection was they'd enable very simple nonvolatile memory, and some other things
40 2013-07-04 00:37:11 <petertodd> Yup, but for enabling non-volatile memory you actually want something that doesn't behave very much like an ideal memristor apparently.
41 2013-07-04 00:37:36 <nsh> hmm
42 2013-07-04 00:38:00 <petertodd> Same way if you want to filter RF noise, you actually don't want something that behaves like an ideal inductor, because the non-ideal effects like increased real-resistance at high frequencies are actually useful.
43 2013-07-04 00:38:38 <nsh> right
44 2013-07-04 00:38:45 <nsh> oh, synaptic modelling was the other application
45 2013-07-04 00:38:59 <bombsite> petertodd: I'm still in uni for computer engineering
46 2013-07-04 00:39:16 <bombsite> but might be going grad school for cs
47 2013-07-04 00:39:27 <bombsite> since my areas of interest are crypto, security, malware
48 2013-07-04 00:40:32 <petertodd> nsh: yeah, the synaptic one sounded cool
49 2013-07-04 00:41:32 <petertodd> bombsite: Ah cool, CE is an interesting field, though be careful you don't discount programming too much... The theoretical pure CS stuff is IMO something you can ignore, but you should understand what is good about high-level-language techniques rather than getting stuck in the idea that C is the be all and end-all of languages.
50 2013-07-04 00:42:07 <petertodd> In my experience people who are too hardware oriented often really dismiss modern programming techniques.
51 2013-07-04 00:42:19 <bombsite> oh i'm not hardware oriented at all haha
52 2013-07-04 00:42:43 <bombsite> I'm the type of guy who'd rather write verilog and simulate a circuit than wire it
53 2013-07-04 00:43:18 <petertodd> Ah, well that's still fairly hardware oriented compared to a Lisp programmer. :)
54 2013-07-04 00:44:04 <nsh> if i can be abstracted away, it probably should
55 2013-07-04 00:44:35 <nsh> that way we get great surprises years down the line when some subtle manifestation of the imperfection of our abstractions occurs
56 2013-07-04 00:44:38 <nsh> that's always fun
57 2013-07-04 00:46:45 <nsh> (i am an adherent of the Erisian order)
58 2013-07-04 00:49:03 <bombsite> stop being sesquipedalian, prick :P
59 2013-07-04 00:59:17 <petertodd> Heh, yeah abstractions have their downsides too... I'm mainly thinking about VHDL and verilog, where so much could have been done to even just automate things a bit.
60 2013-07-04 00:59:22 <petertodd> Especially verilog, gah.
61 2013-07-04 01:08:00 <bombsite> I think the problem
62 2013-07-04 01:08:13 <bombsite> is that the big companies in that field, like altera and xilinx
63 2013-07-04 01:08:22 <bombsite> are companies of EEs and can't program
64 2013-07-04 01:08:47 <bombsite> like seriously, modelsim and synthesis
65 2013-07-04 01:08:52 <bombsite> have different standards
66 2013-07-04 01:09:03 <bombsite> so a module that simulates can potentially not compile.
67 2013-07-04 01:09:08 <bombsite> that's totally retarded
68 2013-07-04 01:09:55 <petertodd> For sure, you see that with the EDA tools too; Altium has scripting in theory, and it sucks. Heck, Altium in general seems to have been made by shitty programmers who don't understand EE either.
69 2013-07-04 01:13:16 <bombsite> LOL
70 2013-07-04 01:25:33 <petertodd> potentially worrying: inputs.io is operated by the same people who run https://www.coinlenders.com, so they have an incentive to be lending out your deposits behind your back. I just send them an email asking about what auditing of deposits they plan to implement, if any.
71 2013-07-04 01:31:07 <warren> "Bitcoin transactions take a hour to confirm. Inputs.io makes it instant with no fees."
72 2013-07-04 01:31:37 <petertodd> warren: They're doing off-chain tx's for account-to-account transfers, just like easywallet does.
73 2013-07-04 01:37:48 <walch> petertodd: I still don't feel all that comfortable with the service as a whole. the fact that I'm still logged in two days later is worrying enough.
74 2013-07-04 01:38:51 <petertodd> On the other hand, they do make it possible to see where you are logged in, so they are taking that stuff seriously, just not making the same choices you might.
75 2013-07-04 01:39:16 <petertodd> They also have google auth 2 factor.
76 2013-07-04 01:39:28 <warren> my coinbase login from weeks ago is still working ... and I'm coming from an IP 3,000 miles away from the previous location
77 2013-07-04 01:39:48 <petertodd> warren: Well that's based on a cookie in your browser of course.
78 2013-07-04 01:41:07 <petertodd> I said before that the thing these sites need to do is make it possible to use Bitcoin hardware wallets to authorize payments by having those wallets sign dummy transactions or something.
79 2013-07-04 01:42:43 <walch> the thing is, even my online bank is a lot more paranoid about how they deal with logged in users, and they have the luxury of having reversible transactions.
80 2013-07-04 01:44:13 <petertodd> Depends on your threat model; for me because I don't lend my computer to others the convenience of not having to login again outweights the slight risk.
81 2013-07-04 01:44:22 <petertodd> What they should do is make the logout timer configurable.
82 2013-07-04 01:46:05 <walch> in which case I'm struggling to find a use for the website. if it's just for me to use at home, wouldn't a traditional client be more valuable to the end user?
83 2013-07-04 01:46:50 <walch> I realise that transactions under 0.01BTC are awkward in a normal client, but is there really a demand for sub-cent transactions at the moment?
84 2013-07-04 01:46:53 <petertodd> ...um... don't login Bitcoin *anything* on computers for which you don't trust the security.
85 2013-07-04 01:47:11 <petertodd> After all, you can always hit the "logout" button.
86 2013-07-04 01:47:23 <petertodd> But if that's an issue, chances are you are doing it wrong anyway.
87 2013-07-04 01:48:07 <walch> I'm trying to come up with a justification for storing currency on inputs.io rather than a traditional, locally based client.
88 2013-07-04 01:48:52 <petertodd> Privacy is a good one. I would much rather have inputs.io or easywallet.org know what transactions I've made than have anyone who wants to able to use blockchain analysis to figure that out.
89 2013-07-04 01:51:06 <walch> obfuscation, got it.
90 2013-07-04 01:51:46 <petertodd> It's not obfuscation, it's genuine privacy. Only inputs.io can link those transactions together, not anyone else. Easywallet can be used over Tor FWIW...
91 2013-07-04 01:53:50 <walch> privacy would suggest that nobody knows; surely that's placing trust in the operator of the websites not to divulge their logs at a later date.
92 2013-07-04 01:54:56 <petertodd> walch: Sure, but in many cases that's a reasonable assumption. With easy wallet it's even better because you can always make more than one account and send funds from one to another, something people already do to send funds to other people.
93 2013-07-04 02:06:37 <walch> petertodd: I can see the service having a merit in that sense.
94 2013-07-04 09:26:16 <warren> https://github.com/bitcoin/bitcoin/pull/2809 <--- Why was this closed without merging?
95 2013-07-04 09:38:31 <gmaxwell> warren: it was closed by the requestor. not clear why.
96 2013-07-04 10:06:27 <phantomcircuit> that reminds me i should close the pull request about speeding up wallet load times
97 2013-07-04 10:06:35 <phantomcircuit> sipa said he wanted to just change the format entirely
98 2013-07-04 10:07:01 <phantomcircuit> and people are still complaining about the copy/pasted openssl code's format
99 2013-07-04 11:43:25 <walch> warren: I closed it so that I could add a little more to it
100 2013-07-04 11:44:36 <walch> warren: I need to have a chat with laanwj and work out how some of the strings work in QT before I open a new pull
101 2013-07-04 11:47:20 <warren> walch: cool,t hx
102 2013-07-04 11:53:51 <warren> [warren@newcaprica litecoin]$ ./bitcoin-qt -testnet
103 2013-07-04 11:53:53 <warren> terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
104 2013-07-04 11:53:55 <warren> what(): boost::filesystem::create_directory: No such file or directory: "/home/warren/.bitcoin/testnet3"
105 2013-07-04 11:53:58 <warren> Aborted (core dumped)
106 2013-07-04 11:54:04 <warren> bitcoin master ... -testnet fails first time, works on second attempt
107 2013-07-04 11:54:26 <warren> can anyone reproduce?
108 2013-07-04 11:55:33 <walch> I can't reproduce that on OSX.
109 2013-07-04 12:39:53 <Steve132> Whats the best way to submit a bitcoin improvement proposal?
110 2013-07-04 12:56:27 <Zx82> Buy 2 BTC by paypal usd
111 2013-07-04 13:05:11 <Steve132> What's the best way to submit a BIP?
112 2013-07-04 13:13:47 <michagogo> Steve132: SOmeone may have linked you already, but https://en.bitcoin.it/wiki/BIP
113 2013-07-04 13:14:06 <michagogo> People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
114 2013-07-04 13:20:47 <Steve132> Second question..in public-key cryptography, can you encrypt a message with a public key but not use diffie helman?
115 2013-07-04 13:20:51 <tcatm> sipa: Wouldn't the commits be "squeezed" into a single merge commit anyway?
116 2013-07-04 13:21:15 <Steve132> like, can you encrypt a message such that the recipiant can read it but it doesn't use your keys?
117 2013-07-04 13:21:43 <sipa> Steve132: yes
118 2013-07-04 13:21:54 <sipa> Steve132: well, there are schemes that don't use DH
119 2013-07-04 13:21:55 <Steve132> What's the name of that?
120 2013-07-04 13:22:07 <sipa> RSA encryption doesn't use DH
121 2013-07-04 13:22:50 <sipa> tcatm: the criterion is usually that at every commit, the program should build and work
122 2013-07-04 13:22:59 <sipa> tcatm: which i guess is true for your PR actually
123 2013-07-04 13:23:21 <sipa> tcatm: but still, 7 commits for a few lines changed
124 2013-07-04 13:23:24 <Steve132> Can you use EC to do the same thing?
125 2013-07-04 13:23:33 <sipa> Steve132: there is no EC-RSA
126 2013-07-04 13:23:56 <Steve132> like, encrypt a message with a EC public key s.t. only the EC private key can decrypt it, but not use ECDH
127 2013-07-04 13:24:20 <sipa> there may be direct EC-based encryption, but in practice ECDH is always used to establish a ephemeral key
128 2013-07-04 13:24:22 <tcatm> sipa: Looks better now?
129 2013-07-04 13:24:50 <sipa> tcatm: thanks!
130 2013-07-04 13:25:07 <tcatm> What's the procedure for merging pull requests? Who does it and when?
131 2013-07-04 13:26:15 <sipa> tcatm: anyone with write access can, we usually wait for a few ACKs
132 2013-07-04 13:31:09 <Steve132> A few days ago when people were talking about embedding data transactions into the blockchain by using targeted amounts of bitcoin
133 2013-07-04 13:31:26 <Steve132> like, using 0.0001323433 btc to send that particular string as data
134 2013-07-04 13:31:47 <Steve132> and there was a scandal because someone supposedly put CP links on there
135 2013-07-04 13:31:59 <Steve132> Why didn't they just use the 'message'
136 2013-07-04 13:32:13 <sipa> which 'message'
137 2013-07-04 13:32:13 <Steve132> like, aren't transaction messages embedded in the blockchain as data?
138 2013-07-04 13:32:29 <sipa> there is no public message field in bitcoin transactions
139 2013-07-04 13:32:30 <Steve132> like the message associated with the genesis block
140 2013-07-04 13:32:34 <sipa> and there should not be one
141 2013-07-04 13:32:43 <sipa> coinbases are special
142 2013-07-04 13:33:02 <sipa> the blockchain is a very slow unreliable and expensive communication mechanis.
143 2013-07-04 13:35:59 <Steve132> https://blockchain.info/tx/bfe855b9daefc36a493b447e2137f97a8e906f83ff517f2ced42d56c3c41fd8d
144 2013-07-04 13:37:03 <Steve132> The script for transactions allows you to use OP_DROP to put arbitrary data in...and blockchain.info uses that as a 'public note' field
145 2013-07-04 13:38:53 <Steve132> am I wrong?
146 2013-07-04 13:40:26 <Steve132> https://en.bitcoin.it/wiki/Script#Transaction_with_a_message
147 2013-07-04 13:50:42 <Steve132> sipa: what am I looking at if you cannot embed messages in the blockchain?
148 2013-07-04 13:50:47 <petertodd> Steve132: You are wrong; look at the actual transaction; there's no OP_DROP there.
149 2013-07-04 13:51:11 <Steve132> So what am I looking at?
150 2013-07-04 13:51:16 <Steve132> and what does the wiki mean?
151 2013-07-04 13:51:18 <sipa> a central database
152 2013-07-04 13:51:28 <sipa> blockchain.info allows you to associate messages with transactions
153 2013-07-04 13:51:35 <sipa> but that's purely stored at blockchain.info
154 2013-07-04 13:51:49 <sipa> and yes, in theory you can use OP_DROP to put messages in scripts
155 2013-07-04 13:51:54 <sipa> but it's not standard and you shouldn't
156 2013-07-04 13:52:19 <Steve132> sipa: why not?
157 2013-07-04 13:52:43 <Steve132> It would enable a fully decentralized marketplace, for one
158 2013-07-04 13:53:26 <Steve132> are there technical problems associated with doing it?
159 2013-07-04 13:53:33 <TD> why would it enable a fully decentralised marketplace?
160 2013-07-04 13:53:42 <TD> yeah, a whole bunch. that's why b.i switched to using its own database
161 2013-07-04 13:54:14 <Steve132> what are the techincal problems?
162 2013-07-04 13:54:33 <sipa> requiring the world to mirror your personal data for eternity
163 2013-07-04 13:54:35 <petertodd> Steve132: the data has to be stored forever in the blockchain for no good reason
164 2013-07-04 13:54:53 <TD> also, the data allowed is very small (too small for most useful messages) and it's public
165 2013-07-04 13:55:17 <TD> there are usually better ways. sometimes for various reasons it's actually important that you have data which is signed atomically with a financial transaction and OP_DROP is there for that reason
166 2013-07-04 13:55:21 <TD> but mostly it's unnecessary
167 2013-07-04 13:55:41 <Steve132> Well, 1) its like 1K, which is plenty for stuff. One of the largest communication networks in the world is 160 bytes
168 2013-07-04 13:55:57 <Steve132> 2) encryption would make it not public
169 2013-07-04 13:56:10 <petertodd> Steve132: 160 bytes adds up.
170 2013-07-04 13:56:26 <Steve132> and yes, thats the point, "sometimes for various reasons its important you have data which is signed atomically with a financial transaction"
171 2013-07-04 13:56:31 <petertodd> Steve132: Anyway, the real issue is people don't want you to do what you are trying to do and will raise hell and high water trying to stop you.
172 2013-07-04 13:56:32 <Steve132> thats exactly what I'm asking about
173 2013-07-04 13:57:14 <Steve132> Why raise hell and high water? They could simply reject the transaction or require higher fees
174 2013-07-04 13:57:24 <TD> unless you have developed an interesting new financial cryptography protocol, you almost certainly don't need OP_DROP
175 2013-07-04 13:57:28 <TD> but maybe you have
176 2013-07-04 13:57:30 <petertodd> Steve132: Do you know what the UTXO set is?
177 2013-07-04 13:57:52 <Steve132> the unspent transactions yes
178 2013-07-04 13:57:53 <TD> what higher level problem are you wanting to solve?
179 2013-07-04 13:58:03 <TD> (decentralized marketplace is a bit vague)
180 2013-07-04 13:58:05 <petertodd> Steve132: Do you realize that we need to keep it small?
181 2013-07-04 13:58:36 <Steve132> Well, if you could embed data with the financial transaction
182 2013-07-04 13:59:11 <sipa> Steve132: the financial transaction is more than the bitcoin transaction backing it
183 2013-07-04 13:59:14 <sipa> or at least, can be
184 2013-07-04 13:59:16 <Steve132> then you could be like "1 widget. Part no 2031." and encrypt it using the public key of the destination address
185 2013-07-04 13:59:24 <Steve132> and send that as a message
186 2013-07-04 13:59:28 <Steve132> along with the payment
187 2013-07-04 13:59:32 <sipa> how about just sending it to the the only person in the world who cares directly?
188 2013-07-04 13:59:53 <sipa> instead of making it part of the piece of data the entire world needs to validate it (the bitcoin transaction)
189 2013-07-04 14:00:08 <sipa> (which is exactly what the payment protocol - which is being developed - does)
190 2013-07-04 14:00:45 <Steve132> The benefit of making it something the entire world needs to validate is that the terms of an agreement are just as important for independant validation of an exchange as the amount paid is
191 2013-07-04 14:00:57 <TD> Steve132: see this: https://github.com/bitcoin/bitcoin/pull/2539
192 2013-07-04 14:01:17 <TD> Steve132: if the merchant supports it, you end up with a proof of payment request, and proof that you paid it
193 2013-07-04 14:01:25 <TD> Steve132: but it doesn't add anything to the block chain and the communication is direct
194 2013-07-04 14:01:30 <TD> it seems a superior approach
195 2013-07-04 14:02:16 <sipa> Steve132: if the data is encrypted anyway, it's useless to everyone else anyway
196 2013-07-04 14:02:23 <petertodd> Steve132: Do you realize that we can add a P2P flood-fill messaging layer to Bitcoin to send messages that don't need to go in the blockchain itself?
197 2013-07-04 14:02:45 <Steve132> these are all good ideas
198 2013-07-04 14:02:51 <Steve132> thanks for the food for thought
199 2013-07-04 14:02:59 <petertodd> Steve132: np
200 2013-07-04 14:20:15 <petertodd> BlueMatt: Can you give the pull-tester a kick? (sure someone else has already asked you...)