1 2014-02-02 00:28:23 <andytoshi> if we can maintain 1.75%/day growth rate we'll be an an exahash by this time next year o.O
2 2014-02-02 00:54:01 <nsh> i wonder what the most executed algorithm in history is...
3 2014-02-02 00:54:24 <nsh> maybe something conserved widely from BSD sockets code or something
4 2014-02-02 00:55:02 <nsh> or already SHA-1...
5 2014-02-02 00:58:31 <andytoshi> well, if you consider "increment the instruction pointer" to be an algorithm, it's got them all beat :P
6 2014-02-02 01:37:31 <nsh> andytoshi, yeah, it's hard to draw the line
7 2014-02-02 01:52:48 <iateadonut> sipa, so if i do something like decoderawtransaction $rawtrans, where would it show me the confirmations?
8 2014-02-02 02:03:07 <sipa> iateadonut: it cannot
9 2014-02-02 02:03:18 <sipa> decoderawtransaction only decodes a transaction
10 2014-02-02 02:03:35 <sipa> to know the confirnations, you need to look it up in the blockchain
11 2014-02-02 02:19:49 <omefire> test
12 2014-02-02 02:38:33 <iateadonut> sipa, what commands are used to do that?
13 2014-02-02 02:41:11 <iateadonut> can this only be done natively from one's own wallet?
14 2014-02-02 02:44:52 <iateadonut> if that's the case, it must be why API services make you open a wallet on their server.
15 2014-02-02 03:02:01 <iateadonut> any answer is appreciated. (thanking in advance because i'm about to fall asleep)
16 2014-02-02 03:06:03 <fanquake> gavinandresen Nice work on the gitian write up
17 2014-02-02 03:26:01 <tlrobinson> gavinandresen_ fanquake I added VirtualBox support to gitian's make-base-vm using Vagrant: https://github.com/tlrobinson/gitian-builder/commit/a6fdc2883949dcee8caefba523d1c3d590d0efe3
18 2014-02-02 03:28:05 <tlrobinson> it occurred to me that Vagrant overlaps a bit with some of gitia-builder's scripts, e.x. start-target = vagrant up, stop-target = vagrant suspend, on-target = vagrant ssh -c 'command', etc
19 2014-02-02 03:28:50 <tlrobinson> plus there are vagrant providers for kvm, lxc, etc
20 2014-02-02 03:30:44 <tlrobinson> gavinandresen_: i'm not sure this is 100% correct though, i built boost successfuly but the hashes don't match what I see in your blog post
21 2014-02-02 03:31:16 <fanquake> tlrobinson Nice. Will look at it later.
22 2014-02-02 04:39:51 <dkog> hi - can anybody point me toward a good random analyzer? ie. to check uniformity, etc.
23 2014-02-02 04:40:36 <dkog> Anything in python maybe?
24 2014-02-02 04:47:53 <magbo> dkog: python people would greatly benefit from such a tool, if you know what I mean.
25 2014-02-02 04:48:12 <magbo> jokes aside, here's where you should start your tests (imho): http://manpages.ubuntu.com/manpages/precise/man1/dieharder.1.html
26 2014-02-02 04:48:22 <dkog> magbo: I know what you mean literally, but I think I'm missing the innuendo...
27 2014-02-02 04:50:50 <magbo> dkog: sorry, didn't imply anything, just made a joke. Do you have any specific reason not to use dieharder?
28 2014-02-02 04:51:30 <dkog> No, that's the one I've heard about before, just wondering if there was anything else, lighter, easier, maybe even a web service you could upload a data set to...
29 2014-02-02 04:53:45 <magbo> dkog: sorry, I don't know of such a thing. I can try to search for it but I don't think that it's needed. Maybe other people here will have a better answer.
30 2014-02-02 05:25:42 <dkog> I moved my question to #crypto, where they are telling me how futile such things are :)
31 2014-02-02 05:27:19 <magbo> dkog: well, we all know that. âWith randomness you can never be sureâ. So I skipped to trying my best to answer your question/
32 2014-02-02 05:28:44 <dkog> There is the example of using the bit stream from sha256(1), sha256(2), ... which looks random and passes all tests, but is 100% predictable.
33 2014-02-02 08:44:46 <michagogo> cloud|tlrobinson: still around?
34 2014-02-02 08:45:37 <tlrobinson> michagogo|cloud: yeah
35 2014-02-02 08:45:48 <michagogo> cloud|What method did you use to gbuild?
36 2014-02-02 08:45:55 <michagogo> cloud|And, what hashes do you get?
37 2014-02-02 08:46:08 <michagogo> cloud|I built using LXC, and didn't match Gavin
38 2014-02-02 08:46:46 <tlrobinson> i used virtualbox (using those changes to gitian-builder i linked to)
39 2014-02-02 08:46:58 <tlrobinson> i didn't save the hashes, i can run it again though
40 2014-02-02 08:49:20 <tlrobinson> (it's going to take a bit though)
41 2014-02-02 08:49:34 <michagogo> cloud|tlrobinson: I commented with my result on https://github.com/bitcoin/bitcoin/issues/3612
42 2014-02-02 08:49:34 <tlrobinson> i suppose i should also make sure multiple runs produce the same hashes
43 2014-02-02 08:51:10 <tlrobinson> michagogo|cloud: are you on master?
44 2014-02-02 08:51:24 <michagogo> cloud|v0.9.0rc1
45 2014-02-02 08:51:43 <michagogo> cloud|checked out in git, and passed in the --commit argument
46 2014-02-02 08:51:49 <michagogo> cloud|(following doc/release-process.md)
47 2014-02-02 08:51:54 <tlrobinson> i was probably on master actually
48 2014-02-02 08:53:51 <michagogo> cloud|tlrobinson: That might have something to do with it
49 2014-02-02 08:53:56 <michagogo> cloud|ACTION checks the git logs
50 2014-02-02 08:54:55 <michagogo> cloud|tlrobinson: Maybe, but maybe not: https://github.com/bitcoin/bitcoin/compare/v0.9.0rc1...master
51 2014-02-02 08:55:12 <michagogo> cloud|I don't know if what you call the commit has anything to do with it
52 2014-02-02 08:55:21 <michagogo> cloud|or if it's just the contents
53 2014-02-02 08:56:07 <michagogo> cloud|tlrobinson: To clarify, do you mean you passed --commit bitcoin=master?
54 2014-02-02 08:56:15 <michagogo> cloud|or just that you had master checked out in the git tree?
55 2014-02-02 08:57:22 <tlrobinson> michagogo|cloud: i followed the instructions here exactly http://gavintech.blogspot.com/2014/02/gitian-building-bitcoin-releases.html
56 2014-02-02 08:57:36 <michagogo> cloud|ACTION hasn't seen that
57 2014-02-02 08:57:37 <tlrobinson> which includes "--commit bitcoin=HEAD"
58 2014-02-02 08:58:12 <tlrobinson> (i only built boost and noticed it didn't match gavin's output)
59 2014-02-02 08:58:37 <michagogo> cloud|tlrobinson: Oh, don't worry about that
60 2014-02-02 08:58:46 <michagogo> cloud|The input dependencies aren't deterministic, IIRC
61 2014-02-02 08:59:13 <tlrobinson> oh, ok. i'll try doing the whole 0.9.0rc1 build then
62 2014-02-02 09:49:18 <fanquake> Quick we'd better shut this whole thing down.. https://github.com/bitcoin/bitcoin/issues/3615
63 2014-02-02 09:51:55 <SomeoneWeird> gmaxwell, lol
64 2014-02-02 09:52:05 <SomeoneWeird> "nsaatlarge" haha
65 2014-02-02 09:53:41 <aynstein> gmaxwell: can I assume you dont believe it was satoshi
66 2014-02-02 09:53:46 <aynstein> ;)
67 2014-02-02 09:54:18 <fanquake> we all believe aynstein :p
68 2014-02-02 09:54:23 <aynstein> or are you an NSA plant?
69 2014-02-02 09:55:40 <aynstein> I will believe anything anyone tells me, up to the point my brain process the incoming signal.
70 2014-02-02 09:56:32 <aynstein> Well, to be fair, when I *first got involved with bitcoin, that thought crossed my mind
71 2014-02-02 10:00:15 <aynstein> sorry, I know some take whats written here out of context, I do not believe gmaxwell is an nsa shrub, or bush, tree or any type of fern or fawna, no plant at al.
72 2014-02-02 10:07:05 <aynstein> why did I try
73 2014-02-02 10:23:33 <aynstein> sorry
74 2014-02-02 10:24:47 <aynstein> i walked into that.
75 2014-02-02 10:35:14 <wumpus> hehe
76 2014-02-02 10:47:35 <SomeoneWeird> Seriously somebodies who is an admin on the github bitcoin repo needs to delete that issue. gmaxwell gavinandresen_ tcatm sipa
77 2014-02-02 10:50:59 <fanquake> SomeoneWeird You can't delete issues from GitHub
78 2014-02-02 10:51:24 <fanquake> Although you could probably ban the user from the repo and then edit all the comments blank.
79 2014-02-02 10:51:41 <SomeoneWeird> gah, right
80 2014-02-02 10:51:48 <SomeoneWeird> well, i reported him, everyone should too
81 2014-02-02 11:01:08 <Diablo-D3> url
82 2014-02-02 11:06:59 <fanquake> Diablo-D3 https://github.com/bitcoin/bitcoin/issues/3615
83 2014-02-02 11:08:03 <Diablo-D3> wow what a fucktard
84 2014-02-02 11:08:13 <Diablo-D3> github can delete the issue btw
85 2014-02-02 11:24:54 <Diablo-D3> gmaxwell: hey, do you know if ipsec includes a method for using asymetric keys for AH?
86 2014-02-02 13:25:08 <Azrael_-> hi
87 2014-02-02 13:30:53 <shamoon> if i want to connec to more than 8 peers, i have to change the source code, ib elieve
88 2014-02-02 13:30:58 <shamoon> where do i make that change?
89 2014-02-02 13:31:15 <michagogo> cloud|shamoon: net.cpp
90 2014-02-02 13:31:20 <shamoon> that's it
91 2014-02-02 13:31:22 <shamoon> thanks michagogo|cloud
92 2014-02-02 13:34:05 <shamoon> michagogo|cloud: that's MAX_OUTBOUD
93 2014-02-02 13:34:08 <shamoon> is that the same as inbound?
94 2014-02-02 13:34:14 <shamoon> peeps that connect to me?
95 2014-02-02 13:37:09 <michagogo> cloud|No
96 2014-02-02 13:38:40 <shamoon> any way to change that?
97 2014-02-02 13:39:12 <michagogo> cloud|Yes
98 2014-02-02 13:39:20 <michagogo> cloud|Configuration option
99 2014-02-02 13:40:38 <Azrael_-> is there a way to look into the sourcecode and learn the half-rate from it?
100 2014-02-02 14:14:40 <michagogo> cloud|Azrael_-: I would argue that you can learn any aspect of its behavior if you read and understand the code
101 2014-02-02 14:15:18 <nsh> until we merge the nondeterministic branch, at least
102 2014-02-02 14:23:46 <michagogo> cloud|nsh: uh?
103 2014-02-02 14:24:10 <nsh> just being silly :)
104 2014-02-02 14:25:37 <michagogo> cloud|Even then you could read the code and understand what it does
105 2014-02-02 14:25:49 <aynstein> I am really sorry for antogonizing the unmedicated guy on github
106 2014-02-02 14:25:53 <michagogo> cloud|What random behaviors it can choose
107 2014-02-02 14:26:27 <aynstein> ohhhh eya
108 2014-02-02 14:26:28 <aynstein> yea
109 2014-02-02 14:26:34 <aynstein> kungfu
110 2014-02-02 14:26:36 <aynstein> biotches
111 2014-02-02 14:26:50 <aynstein> haha
112 2014-02-02 14:27:01 <aynstein> ok I am gunna reclaim the mine
113 2014-02-02 14:27:04 <aynstein> :)
114 2014-02-02 15:59:31 <skinnkavaj> Can someone explain why it isn't possible for exchanges to accept payments from pools? And how have mcxNOW succeeded in going around it.
115 2014-02-02 16:02:05 <sipa> i don't see why they couldn't?
116 2014-02-02 16:03:11 <skinnkavaj> sipa: I guess they don't send the recieved coins on withdrawal, but coins deposited earlier that already have all confirmations
117 2014-02-02 16:04:17 <sipa> so?
118 2014-02-02 16:07:27 <kaptah> some exchanges don't like generated coins (eligius) but other than that, haven't heard of any problems
119 2014-02-02 16:08:07 <sipa> sounds like a bug
120 2014-02-02 16:12:12 <CourtJesterG> anybody else try compiling the bitcoin client? Am trying to install boost with homebrew
121 2014-02-02 16:12:26 <CourtJesterG> for this task, it always fails
122 2014-02-02 16:13:08 <CourtJesterG> brew install boost --build-from-source --c++11 --with-icu --with-mpi --without-single --with-python --without --static --HEAD
123 2014-02-02 16:13:08 <CourtJesterG> This may be changed by setting the FC environment variable.
124 2014-02-02 16:13:08 <CourtJesterG> ==> Using Homebrew-provided fortran compiler.
125 2014-02-02 16:13:10 <CourtJesterG> ==> Checking out http://svn.boost.org/svn/boost/trunk
126 2014-02-02 16:13:12 <CourtJesterG> Warning: Formula#python is deprecated and will go away shortly.
127 2014-02-02 16:13:14 <CourtJesterG> Error: Building MPI support for Python using C++11 mode results in
128 2014-02-02 16:13:16 <CourtJesterG> failure and hence disabled. Please don't use this combination
129 2014-02-02 16:13:18 <CourtJesterG> This is what am doing:
130 2014-02-02 16:14:38 <CourtJesterG> Am unsure which should I give up the MPI, PYTHON libraries or C++11
131 2014-02-02 16:15:07 <CourtJesterG> It would be nice to use boost with python, and building the libraries during this helps out
132 2014-02-02 16:16:01 <sipa> you need neither
133 2014-02-02 16:16:16 <CourtJesterG> Can you build it twice? one with support for Python than with out
134 2014-02-02 16:16:16 <sipa> no python, no c++11, no mpi
135 2014-02-02 16:16:49 <sipa> depends on how you link
136 2014-02-02 16:16:58 <skinnkavaj> <sipa> sounds like a bug // A bug. Isn't it a safety function. Because you need to have x confirmations on newly minted coins.
137 2014-02-02 16:17:22 <sipa> skinnkavaj: so? they should count them as soon as they get the required number of confirmations
138 2014-02-02 16:17:40 <skinnkavaj> Yeah but isn't it 300 confirmations or so for new coins?
139 2014-02-02 16:17:44 <sipa> 100
140 2014-02-02 16:18:01 <sipa> 101, actually
141 2014-02-02 16:18:12 <skinnkavaj> How long is that. Days?
142 2014-02-02 16:18:27 <sipa> ;;calc 101*600/3600
143 2014-02-02 16:18:28 <gribble> 16.8333333333
144 2014-02-02 16:18:32 <sipa> 17 hours
145 2014-02-02 16:18:46 <skinnkavaj> I guess the problem is that if exchanges accept pool payments, users will complain that the funds doesn't show up in account balance after 6 confirmations
146 2014-02-02 16:19:03 <sipa> and niw they complain the funds don't count at all :)
147 2014-02-02 16:19:32 <skinnkavaj> Isn't 100 a very long time?
148 2014-02-02 16:19:39 <skinnkavaj> Is it really still needed?
149 2014-02-02 16:19:57 <petertodd> skinnkavaj: 100 is less than a day you know...
150 2014-02-02 16:20:21 <skinnkavaj> But if exchanges accept 6 confirmations, why can't it be like 12 confirmations to spend newly mined oins?
151 2014-02-02 16:20:46 <skinnkavaj> I guess it's protecting from a potentional 51% attack
152 2014-02-02 16:21:11 <petertodd> skinnkavaj: think of it this way: that's basically your response time to fix a fork before coins can end up in the hands of someone other than who mined them; after the fork is fixed coins get destroyed if they aren't on the right side
153 2014-02-02 16:21:34 <petertodd> skinnkavaj: in theory transactions would otherwise get incorporated into the other side of the chian and no-one loses money
154 2014-02-02 16:22:52 <petertodd> e.g. in the march fork transactions tended to wind up getting mined on both sides, so you were actually relatively safe if you had a transaction in progress while it was happening
155 2014-02-02 16:23:14 <skinnkavaj> But with that reasoning shouldn't exchanges use 100 confirmations for safety as well?
156 2014-02-02 16:23:21 <skinnkavaj> For every deposit.
157 2014-02-02 16:23:26 <sipa> skinnkavaj: no
158 2014-02-02 16:23:37 <sipa> there is a very fundamental difference
159 2014-02-02 16:23:52 <skinnkavaj> Whats the fundemental difference?
160 2014-02-02 16:23:54 <sipa> newly minted coins cannot be spent at the protocol level before they are matured
161 2014-02-02 16:23:56 <petertodd> skinnkavaj: no, because normally coins can't vanish out of thin air - they can when a coinbase output is destroyed
162 2014-02-02 16:24:12 <petertodd> (destroyed by being reorged)
163 2014-02-02 16:24:15 <sipa> 6 confirmations is just a policy of the receiver
164 2014-02-02 16:24:20 <sipa> and indeed that is the reason
165 2014-02-02 16:24:31 <sipa> newly minted coins disappear in a reorganization
166 2014-02-02 16:24:56 <sipa> other coins can - absent a double spending attack - just move to the new chain
167 2014-02-02 16:25:21 <skinnkavaj> Alright that exlains it thank you
168 2014-02-02 16:25:25 <sipa> changing the 101 confirmations limit would require a hardfork
169 2014-02-02 16:26:19 <petertodd> note how if you're making an alt-coin with a one minute block interval, you should increase that 101 limit proportionally to give time for people to fix problems - dogecoin should have definitely set it to 1000 or more confs
170 2014-02-02 16:26:54 <petertodd> from a business point of view having a days revenue tied up - even a week's worth - isn't a big deal
171 2014-02-02 16:27:50 <skinnkavaj> mcxNOW have this protection, question is.. How is it done?
172 2014-02-02 16:27:53 <skinnkavaj> Built-in 51% protection for relevant altcoins -
173 2014-02-02 16:27:53 <skinnkavaj> If a 51% attack is detected in any of the Bitcoin-based chains then that exchange will automatically shut down to protect against any abuse. This isn't going to guarantee that you will not lose out if a chain is 51% attacked but it gives some protection against losses.
174 2014-02-02 16:28:14 <skinnkavaj> How is 51% attack detected?
175 2014-02-02 16:28:15 <petertodd> skinnkavaj: they're probably triggering it based on reorg events - good idea
176 2014-02-02 16:29:12 <skinnkavaj> THey also say "This isn't going to gurantee that you will not lose out if a chain is 51% attacked"
177 2014-02-02 16:29:22 <skinnkavaj> Isn't the exchange that will lose on it? And not the end user.
178 2014-02-02 16:29:39 <petertodd> skinnkavaj: if their transfer of coins to you gets wiped out you lose out
179 2014-02-02 16:30:51 <skinnkavaj> Alright thanks
180 2014-02-02 16:33:58 <petertodd> shesek: heard of reality keys? they're doing a pubkey/privkey-release-based oracle service - your bitrated site could make for a fairly easy way to use them with probably relatively minor changes
181 2014-02-02 16:37:36 <shesek> petertodd, yes, I heard of them, but didn't think about this
182 2014-02-02 16:37:58 <shesek> could be interesting to do something like hat... I'll look into it
183 2014-02-02 16:38:02 <petertodd> shesek: if you supported more than one escrow agent you could do it already actually
184 2014-02-02 16:38:58 <petertodd> shesek: I'd suggest you do it in time for the superbowl, but someone would probably say something like it's already happened and I'd just get embarassed
185 2014-02-02 16:52:48 <shesek> petertodd, I'm looking into how the two pubkeys approach works exactly
186 2014-02-02 16:53:17 <petertodd> shesek: cool - fwiw p2sh doesn't have an explicit limit on # of pubkeys
187 2014-02-02 16:53:38 <shesek> yeah, I was just going to ask that - the spending transaction isn't limited to n-of-3?
188 2014-02-02 16:54:00 <shesek> only the funding transaction (which can be overriden with p2sh)?
189 2014-02-02 16:54:56 <petertodd> shesek: bare checkmultisig has a 3 pubkey IsStandard() limit, but that limit wasn't implemented for P2SH
190 2014-02-02 16:54:57 <shesek> is the recommended 2-of-(bob,alice,bob*bob_wins_pubkey,alice*alice_wins_pubkey)?
191 2014-02-02 16:55:03 <petertodd> correct
192 2014-02-02 16:55:13 <shesek> * ... way is
193 2014-02-02 16:55:24 <petertodd> (although sort the pubkeys so they have a canonical order)
194 2014-02-02 16:56:17 <petertodd> you probably also want to just use the pubkeys from reality keys directly for now, having derivation in the mix makes it hard to do the tx's offline
195 2014-02-02 16:56:54 <shesek> how would that work? the revealed private key could be used by both parties
196 2014-02-02 16:56:55 <petertodd> here's a 1-of-12 p2sh I did: 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
197 2014-02-02 16:57:16 <petertodd> doh, yeah your right
198 2014-02-02 16:57:36 <petertodd> oh, and that's even worse because there's no derivation mechanism that works in that case...
199 2014-02-02 16:58:02 <petertodd> or... nah, actually that's wrong, that is ok
200 2014-02-02 16:58:26 <shesek> ... you confused me :)
201 2014-02-02 16:58:28 <shesek> what's ok?
202 2014-02-02 16:59:11 <petertodd> well, with BIP32-style derivation if you release the private key to a derived pubkey the master private key can be obtained with some simple arithmetic
203 2014-02-02 16:59:32 <petertodd> however, in this case you *aren't* revealing the private key to the *derived* key
204 2014-02-02 17:00:23 <petertodd> though I'd need to double check that the math works with someone who actually has a clue - what you're doing there isn't actually BIP32 derivation
205 2014-02-02 17:00:48 <shesek> you mean with the first method of using 2-of-(bob,alice,bob*bob_wins_pubkey,alice*alice_wins_pubkey)?
206 2014-02-02 17:00:53 <petertodd> yup
207 2014-02-02 17:01:59 <petertodd> so, what BIP32 does is takes advantage of the fact that Q_A + d_B*G = (d_A + d_B)*g, but what you want is Q_A + Q_B = (d_A + d_B)*G
208 2014-02-02 17:02:27 <petertodd> I'm pretty sure the later works - Q_B would be reality key's oracle public key - but check with sipa or someone
209 2014-02-02 17:03:42 <shesek> this seems really cool, would be great to add that
210 2014-02-02 17:04:11 <shesek> but its not very trivial to implement on top of bitrated, its gonna require some work
211 2014-02-02 17:04:34 <shesek> also... I have no idea how it'll integrate with the current interface
212 2014-02-02 17:04:52 <shesek> perhaps its better as something separate
213 2014-02-02 17:04:58 <petertodd> what would it take to just make it possible to have a second escrow agent?
214 2014-02-02 17:05:35 <shesek> not much - but how would the users derive the keys and all that?
215 2014-02-02 17:05:52 <petertodd> well they can use a separate tool at first
216 2014-02-02 17:06:07 <petertodd> multiple escrow agents could be a useful feature in general anyway
217 2014-02-02 17:06:34 <shesek> yeah, especially knowing that >3 is standard when using p2sh
218 2014-02-02 17:06:48 <petertodd> yup
219 2014-02-02 17:07:10 <sipa> i'm not sure that's actually intentional
220 2014-02-02 17:07:16 <shesek> I don't understand though - doesn't it consider the spending transaction non-standard, when it sees the script?
221 2014-02-02 17:07:16 <sipa> but i don't really care
222 2014-02-02 17:07:35 <shesek> it seems like an oversight... the spending tx should be non-standard just like the funding tx
223 2014-02-02 17:07:37 <petertodd> sipa: gavin didn't believe me at first, and he wrote the code
224 2014-02-02 17:08:26 <gavinandresen_> mmm. Unintentional side effectâ¦. but could be considered a feature, not a bug
225 2014-02-02 17:08:39 <petertodd> shesek: nope, it's because the way IsStandardTxInput() works is only to check that the input matches one of the standard script templates; the m<=3 test is only present in IsStandard()
226 2014-02-02 17:09:14 <sipa> yeah, the sigops are still accounted for
227 2014-02-02 17:09:34 <sipa> and the up-to-20 pubkeys don't end up in the utxo set anyway
228 2014-02-02 17:09:55 <shesek> ah, I see
229 2014-02-02 17:09:56 <petertodd> sipa: yeah, although p2sh is problematic there because of the 520 byte pushdata limit
230 2014-02-02 17:10:23 <sipa> right, so you can get up to... 14?
231 2014-02-02 17:10:39 <petertodd> sipa: uh, 15 I think?
232 2014-02-02 17:11:04 <sipa> right, 34 bytes per push
233 2014-02-02 17:11:29 <shesek> it sounds more like a bug than a feature... seems like it something that technically should be fixed
234 2014-02-02 17:11:45 <petertodd> shesek: why? it's useful
235 2014-02-02 17:11:46 <shesek> you don't believe IsStandardTxInput() will change eventually to check for that too?
236 2014-02-02 17:11:57 <petertodd> shesek: if you use it for something useful it won't!
237 2014-02-02 17:12:13 <sipa> it's just a local policy thing anyway
238 2014-02-02 17:12:14 <shesek> :)
239 2014-02-02 17:12:31 <shesek> its useful in general, and its still considered non standard when part of a non-p2sh output
240 2014-02-02 17:12:53 <shesek> seems like inputs should technically get the same treatment... or that m<=3 should just be dropped completely
241 2014-02-02 17:13:18 <petertodd> shesek: just be careful - the 500 byte IsStandard() limit on scriptSig's still applies, which means you need to limit your n term as well or you won't be able to get enough signatures
242 2014-02-02 17:13:21 <shesek> well, at least I have peter's word that it won't get "fixed" after I implement something on top of that :D
243 2014-02-02 17:14:17 <petertodd> shesek: IsStandard() is just a matter of conservatism really, and if anything Eligius kinda shows that it's pretty easy to get weird stuff into the blockchain
244 2014-02-02 17:14:35 <sipa> shesek: i see no reason to change that behaviour
245 2014-02-02 17:15:33 <petertodd> sipa: heck, replacing the IsStandard() test with a opcode whitelist isn't crazy IMO, especially for P2SH
246 2014-02-02 17:15:53 <shesek> btw, re. <petertodd> multiple escrow agents could be a useful feature in general anyway
247 2014-02-02 17:15:55 <petertodd> sipa: just make it that you have to consume all stack elements
248 2014-02-02 17:17:01 <shesek> it is, but it doesn't really work well on top of multisig - what you really want is to have multiple agents that have to agree, or some subset of them, something like 2-of-(buyer, seller, m-of-multiple-agents)
249 2014-02-02 17:17:11 <shesek> standard multisig tx aren't really suitable for multiple agents
250 2014-02-02 17:17:41 <petertodd> shesek: true, agents running with the money, gah
251 2014-02-02 17:17:52 <petertodd> shesek: which you can solve by adding yet more pubkeys :/
252 2014-02-02 17:18:01 <shesek> right... 2-of-5 with three agents wouldn't work very well :\
253 2014-02-02 17:18:18 <shesek> yeah, you could double/triple the pubekys the buyer/seller has
254 2014-02-02 17:18:26 <petertodd> shesek: 3-of-4 is reasonable, but then the agent has to be active
255 2014-02-02 17:18:43 <shesek> 4-of-(buyer,buyer,seller,seller,agent1,agent2) or something like that
256 2014-02-02 17:19:03 <petertodd> yup, which just makes you wish you had OP_IF
257 2014-02-02 17:19:17 <wizkid057> seems like just one N of X is limitting. need some more options
258 2014-02-02 17:19:46 <shesek> it is possible to do this properly without hacks like that... with non-standard tx
259 2014-02-02 17:22:21 <petertodd> shesek: oh sure, e.g. <alice> CHECKSIG SWAP <bob> CHECKSIG 2SWAP 1 <escrow1> <escrow2> 2 CHECKMULTISIG ADD ADD
260 2014-02-02 17:23:35 <shesek> right
261 2014-02-02 17:23:43 <shesek> I wonder... does anyone currently use reality keys? how do they do that?
262 2014-02-02 17:23:56 <shesek> its really not trivial for anyone to currently use that
263 2014-02-02 17:24:02 <petertodd> heh, I highly doubt anyone is :)
264 2014-02-02 17:24:59 <shesek> this must suck, starting a service like without anybody using it
265 2014-02-02 17:25:16 <petertodd> I mentioned that to them; they said they were in it for the long haul
266 2014-02-02 17:25:56 <shesek> I'm in an even more annoying position - I can't really tell if anybody is using bitrated
267 2014-02-02 17:26:19 <petertodd> ha, because it's all javacsript?
268 2014-02-02 17:26:20 <shesek> I can see requests going to the multisig page, but no idea how many of those are just tests and how many are actual people depositing funds
269 2014-02-02 17:26:42 <shesek> the server can't see public keys (well, just one of them) and multisig addresses
270 2014-02-02 17:26:54 <petertodd> well, if you never heard from anyone about it that's probably because you did a spectacular job and it's perfect already :P
271 2014-02-02 17:28:07 <petertodd> sipa: incidentally, notice how much more complex that script would have to be if you wanted to banish tx mutability...
272 2014-02-02 17:28:07 <shesek> I do hear about it, I get emails from people who're interested about it and asking questions (no bugs yet, though :)
273 2014-02-02 17:28:22 <shesek> and I see some posts on bitcointalk/reddit mentioning it
274 2014-02-02 17:28:40 <shesek> but its hard to tell what's the actual usage this is getting
275 2014-02-02 17:28:45 <petertodd> well, remember these things take time, and it may be the case that your main contribution is in essentially doing UI/UX research for someone elses project
276 2014-02-02 17:29:46 <sipa> petertodd: let's just fix the scripting language while we're at it
277 2014-02-02 17:30:56 <petertodd> sipa: well sure... but notice how that problem suggests that to fix tx mutability you might be better off making it a non-issue with a new SignatureHash() algorithm or something
278 2014-02-02 17:30:59 <shesek> I'm actually considering to put some more effort on it, I think it has a lot of potential
279 2014-02-02 17:31:27 <petertodd> shesek: me too, and like I say, you don't actually need to have a lot of real-world-usage to make a really big and groundbreaking impact
280 2014-02-02 17:31:28 <shesek> avoiding escrow (and escrow regulation, licensing and costs) allows for some really interesting things that are simply impossible with fiat
281 2014-02-02 17:32:13 <shesek> it doesn't just solve the seller fraud with bitcoin, it can also help solve the buyer fraud merchants are seeing because of the crappy dispute resolution process companies like visa/paypal provides
282 2014-02-02 17:32:39 <petertodd> shesek: yes, although keep in mind that for escrow to work properly you generally need quite a bit of real-world and non-anonymous processes for the agents to be able to come to a correct decision
283 2014-02-02 17:32:39 <shesek> opening the e-commerce arbitration market to competition could be really interesting
284 2014-02-02 17:33:37 <petertodd> shesek: if your DPR, figuring out who screwed who isn't necessarily easy...
285 2014-02-02 17:33:48 <petertodd> *you're
286 2014-02-02 17:35:10 <petertodd> digital products are a nice exception: you certainly could escrow a programming contract given that you can examine the delivered product - the code - very easily
287 2014-02-02 17:36:37 <shesek> well, I'm hoping we'll start seeing bitcoin used more for day-to-day transactions for buying goods&services, and not mainly for speculation as it seems like today
288 2014-02-02 17:37:07 <shesek> and yes, this is a great example, especially because you could have a programmer doing that
289 2014-02-02 17:37:21 <petertodd> well, keep in mind that you need a solid business case - conventional payment systems *do* work really well for a very large class of uses
290 2014-02-02 17:38:01 <shesek> I wanna see someone trying to explain to a rep at visa that they got spaghetti code while the developer promised something else
291 2014-02-02 17:38:23 <shesek> well... they work very well for consumers, not so much for merchants
292 2014-02-02 17:38:41 <petertodd> heh, see, escrow is probably one of those cases where for the right business need bitcoin can in fact offer something conventional systems have a very hard time doing
293 2014-02-02 17:38:48 <shesek> buyer fraud (someone orders a product, gets it, files a dispute and gets to keep both the money and the product) is a very real problem for merchants
294 2014-02-02 17:39:03 <petertodd> but for general purpose "goods and services" I'm unconvinced; buys like visa's protections a lot
295 2014-02-02 17:39:07 <petertodd> *buers
296 2014-02-02 17:39:10 <petertodd> *buyers
297 2014-02-02 17:39:52 <shesek> and they should - its very good at protecting consumers. but it sucks as protecting merchants :-\
298 2014-02-02 17:40:47 <shesek> and that fraud fraud (a few tens of billion dollars a year) is eventually accounted for with higher prices for everyone
299 2014-02-02 17:40:51 <shesek> * buyer fraud
300 2014-02-02 17:41:27 <petertodd> well fraud is a risk like any other; lots of businesses find ways to manage that risk successfully and cheaply enough. you need the whole end-to-end system to be cheaper than the alternative, and that's very hard to accomplish
301 2014-02-02 17:43:04 <petertodd> bitcoin also has the problem that the architecture is kinda insane - I can easily imagine it being thoroughly outcompeted by a cheaper, faster, thing like mintchip if governments had the guts to let it happen
302 2014-02-02 17:43:12 <shesek> it remains to be seen, but I believe that opening the dispute resolution market for competition would end up creating both better services that protects both consumers _and_ merchants, while also making the prices more competitive
303 2014-02-02 17:43:42 <shesek> and avoiding the strict escrow regulations allows doing just that
304 2014-02-02 17:44:08 <shesek> ACTION googles mintchip
305 2014-02-02 17:44:29 <petertodd> maybe - as I say, I'd suggest trying to target a niche within that market that needs the services the most - digital goods does make a lot of sense
306 2014-02-02 17:44:58 <petertodd> might be something where some targetting advertising/promotions really helps "Do you hire programmers in India?"
307 2014-02-02 17:46:37 <shesek> does mintchip operate without a server? just based on exchanging transactions between devices and keeping an internal balance?
308 2014-02-02 17:47:17 <petertodd> that's how it was originally presented, although what they're talking more recently smells like they're doing it differently
309 2014-02-02 17:48:19 <petertodd> keep in mind that it's not a given that "all devices will be hacked eventually" - you *can* build things small enough and sensitive enough that taking them apart without wiping the keys inside is guaranteed impossible by physics
310 2014-02-02 17:50:06 <petertodd> I mean hell, at my last job I routinely designed, built and tested analog electronics with signal levels so low as to be impossible to probe or otherwise measure directly - you simply had to rely on your models of how the things were supposed to be working inside
311 2014-02-02 17:52:04 <shesek> a black box obfuscator could also be really useful here. I just read about some advances in that field a few days ago: https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/
312 2014-02-02 17:52:36 <petertodd> ha, that's a great article, I love how such a thing can turn symmetric crypto into asymmetric
313 2014-02-02 18:01:03 <tlrobinson> how does one determine which types of transactions can currently be used? most Script opcodes are enabled and able to be included in blocked, but only certain combinations of them are considered "standard" and will be relayed? correct?
314 2014-02-02 18:01:25 <petertodd> tlrobinson: look up IsStandard() and AreInputsStandard() in the bitcoin core sourcecode
315 2014-02-02 18:02:20 <petertodd> tlrobinson: Solver() in script.cpp covers all the allowed tx forms mostly
316 2014-02-02 18:03:10 <jcorgan> can anyone point me to reference code for uncompressing compressed public keys? or, bigger picture: i need to import a compressed publice key into a (python-)ecdsa.VerifyingKey, and the closest constructor takes a full curve point, so i think i need to do the conversion
317 2014-02-02 18:03:30 <petertodd> jcorgan: you mean low-level code, or OpenSSL calls?
318 2014-02-02 18:04:16 <jcorgan> well, i'm working in pure python, importing a BIP0032 extended public key, and using an existing pure python ECDSA library
319 2014-02-02 18:04:37 <petertodd> ah, yeah, I dunno - python-bitcoinlib implements the conversion, but using OpenSSL
320 2014-02-02 18:05:08 <petertodd> what's the project?
321 2014-02-02 18:05:28 <tlrobinson> petertodd: thanks. IsStandardTx is used in decided to relay or not, correct? a miner can ignore it and include a tx anyway?
322 2014-02-02 18:05:42 <tlrobinson> *in a block
323 2014-02-02 18:06:02 <jcorgan> i've got a mostly completed BIP0032 key generator that can start with entropy, extended private keys, and extended public keys, to generate child keys with a given hierarchical specification
324 2014-02-02 18:06:04 <sipa> jcorgan: it's quite easy mathematically
325 2014-02-02 18:06:06 <petertodd> tlrobinson: exactly, miners can put damn near anything in a block, the IsStandard() stuff is only a precautionary measure
326 2014-02-02 18:06:13 <sipa> jcorgan: if you don't mind doing the low-level stuff
327 2014-02-02 18:06:22 <jcorgan> sipa: seems so
328 2014-02-02 18:06:33 <jcorgan> just wanted to look at someone else's debugged code :)
329 2014-02-02 18:06:35 <sipa> y^2 = x^3 + 7
330 2014-02-02 18:06:49 <sipa> so compute x^3 + 7, and take a modular square root of it
331 2014-02-02 18:06:56 <jcorgan> its the handling of the y or -y square root i am unsure of
332 2014-02-02 18:07:20 <sipa> well, you check whether y's lowest bit matches the header bit (odd for 0x02, even for 0x03)
333 2014-02-02 18:07:27 <sipa> sorry, even for 0x02 and odd for 0.03
334 2014-02-02 18:07:36 <sipa> and if it's wrong, you take y's complement
335 2014-02-02 18:09:14 <tlrobinson> petertodd: how feasible is it to get non-standard transactions confirmed these days? do you know if any large pools will accept non standard transactions, perhaps with a certain fee size?
336 2014-02-02 18:09:33 <petertodd> tlrobinson: eligus mines them: http://eligius.st/~wizkid057/newstats/pushtxn.php
337 2014-02-02 18:09:57 <jcorgan> ok, i'll have a go at it. it's the last step to getting the first version of this thing out, other than writing up docs
338 2014-02-02 18:10:26 <jcorgan> and it now uses all the new terminology of the revised bip
339 2014-02-02 18:10:57 <tlrobinson> petertodd: is there a consensus among core devs whether this is a good or bad thing?
340 2014-02-02 18:11:20 <petertodd> tlrobinson: dunno about consensus, but it is useful at times
341 2014-02-02 18:13:25 <petertodd> sipa: reminds me, it'd be nice if there was a short section describing why revealing a derived secret key is dangerous, or at least a link to somewhere describing the problem
342 2014-02-02 18:14:03 <sipa> petertodd: saw my pullreq?
343 2014-02-02 18:14:33 <sipa> https://github.com/bitcoin/bips/pull/12
344 2014-02-02 18:15:13 <petertodd> sipa: I was just looking at it; maybe I'm missing something but I don't see that in there
345 2014-02-02 18:15:36 <sipa> it's mentioned two times :)
346 2014-02-02 18:15:49 <petertodd> sipa: right, but it says don't do that - it doesn't say *why*
347 2014-02-02 18:15:56 <sipa> The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information.
348 2014-02-02 18:16:11 <sipa> One weakness that may not be immediately obvious, is that knowledge of the extended public key + any non-hardened private key descending from it is equivalent to knowing the extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level...
349 2014-02-02 18:16:12 <petertodd> sipa: I mean, maybe what I really want is a short theory section describing the basic idea in simplier language
350 2014-02-02 18:16:18 <sipa> in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.
351 2014-02-02 18:16:52 <sipa> feel free to suggest something in easier language
352 2014-02-02 18:17:03 <sipa> ACTION afk
353 2014-02-02 18:17:18 <petertodd> yeah, I should do up a pull-req now that I think I understand it :P
354 2014-02-02 18:20:19 <jcorgan> there is a good mathmatical explanation on bct.org back when it was first discovered, i'll have to go look for that
355 2014-02-02 18:21:00 <petertodd> jcorgan: gmaxwell's description but iddo's was decent I thought, though the latter maybe needed a few more details (though at some point if you don't get it, maybe you should be doing something else!)
356 2014-02-02 18:38:18 <jcorgan> nice, python-ecdsa has a modular square root
357 2014-02-02 18:40:28 <jcorgan> and a modular polynomial based on a vector of coefficients
358 2014-02-02 19:56:18 <devrandom> tlrobinson: send me a pull request for your vagrant stuff?
359 2014-02-02 20:33:20 <sipa> peter
360 2014-02-02 20:33:22 <sipa> eh
361 2014-02-02 20:33:36 <sipa> petertodd: hmm, right, the number of signatures is limited too
362 2014-02-02 20:42:58 <michagogo> cloud|sipa: Have you by any chance gbuilt 0.9.0rc1?
363 2014-02-02 20:45:00 <michagogo> cloud|tlrobinson, did you get those builds done? What're your hashes?
364 2014-02-02 20:46:34 <sipa> michagogo|cloud: no, no time now
365 2014-02-02 20:47:05 <sipa> petertodd: hmm no, the signature are individual scriptSig pushes
366 2014-02-02 20:55:38 <skinnkavaj> sipa: Working on a new exchange would you recommend using a new address for every deposit?
367 2014-02-02 20:56:10 <skinnkavaj> Some users will probably deposit to the old addresses anyway and not listen.
368 2014-02-02 20:56:46 <sipa> i would recommend using a new address for every transaction under every condition
369 2014-02-02 20:56:56 <sipa> though make sure you accept transactions to the old ones
370 2014-02-02 20:57:59 <skinnkavaj> sipa: What if someone hacks into the exchange server and steals all the wallet addresses
371 2014-02-02 20:58:07 <skinnkavaj> Then all the old ones will not work anyway.
372 2014-02-02 20:58:49 <skinnkavaj> Or they will work to deposit to, but the hacker might be faster than the exchange to move coins to new addresses
373 2014-02-02 20:59:00 <skinnkavaj> See the problem?
374 2014-02-02 20:59:03 <sipa> no
375 2014-02-02 20:59:19 <sipa> someone hacking your exchange server is a problem
376 2014-02-02 20:59:31 <sipa> but i don't see how reusing addresses or not makes any difference
377 2014-02-02 21:01:52 <skinnkavaj> sipa: I feels like it's inevitable to happen, that the server might be hacked once in its lifetime.. And then you need to sweep out all addresses generated.
378 2014-02-02 21:02:42 <sipa> yes, but how does reusing address or not make any difference?
379 2014-02-02 21:02:58 <sipa> good that you're expecting that :)
380 2014-02-02 21:03:10 <skinnkavaj> If you tell people that you cannot deposit to older addresses right from start
381 2014-02-02 21:03:21 <jcorgan> inb4 sipa on using public only key generation :)
382 2014-02-02 21:03:30 <sipa> inb4?
383 2014-02-02 21:03:32 <skinnkavaj> That will not ammter.
384 2014-02-02 21:03:40 <skinnkavaj> matter.
385 2014-02-02 21:03:43 <jcorgan> ;;ud inb4
386 2014-02-02 21:03:44 <gribble> http://www.urbandictionary.com/define.php?term=inb4 | Generally used on internet forums, inb4 refers to a user posting a reply to a message/topic "before" another user posts an obvious response. When u...
387 2014-02-02 21:03:49 <michagogo> cloud|sipa: jcorgan is predicting you're about to say that
388 2014-02-02 21:04:07 <skinnkavaj> jcorgan: How will public only key generation help?
389 2014-02-02 21:04:19 <sipa> the exchange server needs access to the private keys anyway
390 2014-02-02 21:04:22 <jcorgan> if your server gets hacked, there is no way for the hacker to spend from the addresses
391 2014-02-02 21:04:29 <skinnkavaj> How?
392 2014-02-02 21:04:35 <jcorgan> they don't have the private keys
393 2014-02-02 21:04:47 <sipa> ?
394 2014-02-02 21:04:50 <skinnkavaj> I have to assume they will have all the private keys if the main exchange wallet is hacked.
395 2014-02-02 21:05:16 <sipa> at least when people withdraw money, the server handling that needs access to the keys
396 2014-02-02 21:05:48 <jcorgan> right, but that doesn't have to be the same server
397 2014-02-02 21:05:50 <skinnkavaj> Maybe all addresses on the exchange should be pregenerated
398 2014-02-02 21:05:58 <skinnkavaj> Like a pool of addresses
399 2014-02-02 21:06:07 <skinnkavaj> pregenerated offline.
400 2014-02-02 21:06:11 <sipa> no need for that, with deterministic address generation
401 2014-02-02 21:06:18 <michagogo> cloud|skinnkavaj: A large address pool has the same effect as a deterministic pubkey generation
402 2014-02-02 21:06:24 <michagogo> cloud|Same issues, etc
403 2014-02-02 21:06:31 <skinnkavaj> So it doesn't help me?
404 2014-02-02 21:06:34 <sipa> it does
405 2014-02-02 21:06:38 <michagogo> cloud|(except for the added need to replenish)
406 2014-02-02 21:06:42 <skinnkavaj> Why does it help?
407 2014-02-02 21:06:44 <sipa> if your withdraw and exchange server are separate machines
408 2014-02-02 21:06:56 <michagogo> cloud|No, generating random addresses offline doesn't help
409 2014-02-02 21:08:00 <jcorgan> the exchange server only has the ability to generate deterministic public keys, not the private key associated with them
410 2014-02-02 21:08:34 <jcorgan> the withrawal "server", which doesn't have to be public facing, can generate the deterministic private keys needed to move btc from those addresses
411 2014-02-02 21:10:14 <skinnkavaj> How can it create public addresses without knowing the private key?
412 2014-02-02 21:10:19 <jcorgan> BIP0032
413 2014-02-02 21:10:21 <skinnkavaj> How is the exchange suppose to spend from the private keys?
414 2014-02-02 21:11:17 <phantomcircuit> jcorgan, generally speaking the distinction between an exchange server and the withdrawal server is pointless
415 2014-02-02 21:12:01 <phantomcircuit> it's impossible for an exchange to operate with the performance people expect unless it can be 99.99% certain account balances are correct
416 2014-02-02 21:12:44 <jcorgan> ACTION admits this kind of services architecture is not his area of expertise
417 2014-02-02 21:13:22 <phantomcircuit> jcorgan, generally speaking if an attacker can compromise the database server they can fake records such that the separation of concerns is pointless
418 2014-02-02 21:13:40 <phantomcircuit> the only advantage in separating them is that the addresses for deposits remain secure
419 2014-02-02 21:13:49 <phantomcircuit> either way the hot wallet gets emptied though
420 2014-02-02 21:15:45 <skinnkavaj> phantomcircuit: What's your solution?
421 2014-02-02 21:16:40 <skinnkavaj> I have a choice to make.. 1. Allow deposit to all older addresses 2. Only use deposit adresses once.
422 2014-02-02 21:16:48 <phantomcircuit> skinnkavaj, separate bitcoind for deposit/withdrawal, rate limit transfers to the withdrawal daemon
423 2014-02-02 21:17:01 <phantomcircuit> set a maximum amount that can be on it at any point
424 2014-02-02 21:17:11 <phantomcircuit> now audit everything
425 2014-02-02 21:17:13 <phantomcircuit> constantly
426 2014-02-02 21:17:45 <phantomcircuit> skinnkavaj, allow deposits to older addresses but discourage it by not showing anything but their current address
427 2014-02-02 21:18:00 <phantomcircuit> the customer support from not accepting older addresses is ridiculous
428 2014-02-02 21:18:56 <skinnkavaj> the customer support from not accepting older addresses is ridiculous // Do you run a service like this yourself or have you read about complaints?
429 2014-02-02 21:20:19 <skinnkavaj> For a feature like auto-selling on every deposit, you have to use the same deposit address every time I guess
430 2014-02-02 21:20:20 <phantomcircuit> skinnkavaj, yes
431 2014-02-02 21:21:53 <skinnkavaj> allow deposits to older addresses but discourage it by not showing anything but their current address // I guess this is the best way to do it. But then you cannot have a auto-sell on every deposit feature.
432 2014-02-02 22:20:16 <benkay> what's the hot jam for running pools these days? eloipool?
433 2014-02-02 22:24:13 <jcorgan> sip: have importing extended public keys working now, thanks for the tips
434 2014-02-02 22:24:23 <jcorgan> sipa