1 2014-01-17 00:58:59 <Anaru> Laptop|Hey guys, newbie here I have a few questions
2 2014-01-17 00:59:31 <Anaru> Laptop|I have two things I need to do
3 2014-01-17 01:00:46 <Anaru> Laptop|First thing I'm trying to do is split an incoming payment to one address to two different addresses, so if I sent 1 BTC to address A, it'll then send .5 BTC to addresses B and C
4 2014-01-17 01:02:46 <Anaru> Laptop|Second thing I'm trying to do is automate an account setup for my website after a bitcoin payment has been recieved
5 2014-01-17 01:02:51 <lianj> .49991 to b and c you mean
6 2014-01-17 01:02:59 <Anaru> Laptop|yes
7 2014-01-17 01:03:09 <lianj> eh not 1 at the end. sorry
8 2014-01-17 01:03:44 <Anaru> Laptop|Now for the first thing, I found an online site that does it, but it's very new (Jan. 12 of this year) and I'm not sure if I trust it
9 2014-01-17 01:04:59 <Anaru> Laptop|Even though the payments I intend to take are very small (.01 btc)
10 2014-01-17 07:05:06 <CodeShark> opinions? https://github.com/CodeShark/bitcoin/compare/coinparams_new
11 2014-01-17 07:34:45 <swulf--> CodeShark: what's the goal? one codebase for all alt coins?
12 2014-01-17 07:34:54 <CodeShark> yes
13 2014-01-17 07:35:01 <CodeShark> or at least a good number of them
14 2014-01-17 07:35:59 <swulf--> seems like a maintenence nightmare :)
15 2014-01-17 07:36:32 <CodeShark> having to support a bunch of different codebases for different alts, all forked off of bitcoind at different points seems like a bigger nightmare :)
16 2014-01-17 07:36:49 <swulf--> but that maintenence task is shared by all the individual coin maintainers
17 2014-01-17 07:37:10 <Arnavion> And it acts to weed out the ones who don't know what they're getting into
18 2014-01-17 07:37:17 <swulf--> there's that too
19 2014-01-17 07:37:32 <CodeShark> there are a bunch who don't know what they're getting into :p
20 2014-01-17 07:37:35 <CodeShark> dogecoin?
21 2014-01-17 07:37:45 <CodeShark> I think we've already crossed that threshold
22 2014-01-17 07:38:46 <swulf--> whoever maintains the official all-coins codebase, would have ultimate say on whether a new coin would be allowed or not?
23 2014-01-17 07:39:06 <CodeShark> why's that?
24 2014-01-17 07:39:19 <swulf--> why would they accept crapcoin.conf into the codebase?
25 2014-01-17 07:39:31 <swulf--> along with my sha796 hashing method
26 2014-01-17 07:39:34 <CodeShark> the parameters are determined at runtime - and the plan is to support compiletime switches for linking in specific modules (i.e. hash functions)
27 2014-01-17 07:40:26 <CodeShark> sure, the configurability would be constrained to the set of exposed parameters and module types
28 2014-01-17 07:40:49 <CodeShark> but a good portion of the protocol is essentially fixed (i.e. core message structures)
29 2014-01-17 07:41:11 <swulf--> doesn't namecoin make some significant reinterpretations on scripts?
30 2014-01-17 07:41:25 <CodeShark> the script interpreter could also be linked in as a module
31 2014-01-17 07:41:34 <wumpus> swulf--: we won't accept altcoin-specific stuff in the codebase
32 2014-01-17 07:41:49 <wumpus> swulf--: otherwise you indeed get discussions 'ohh why his coin and not mine??!!'
33 2014-01-17 07:41:54 <swulf--> right
34 2014-01-17 07:42:15 <CodeShark> yeah, agreed 100% - but none of this needs to be altcoin-specific
35 2014-01-17 07:42:16 <wumpus> bitcoin is bitcoin, and we'd like to reduce the amount of code in bitcoin/bitcoin not blow it up
36 2014-01-17 07:44:48 <CodeShark> the way I see it we could have a peer manager layer that does peer discovery, manages connections to peers, and queues up messages which is agnostic to script contents and configurable to use specific network parameters and hash functions
37 2014-01-17 07:45:24 <CodeShark> then atop this we have a verification engine that checks messages and updates chainstate
38 2014-01-17 07:45:37 <CodeShark> and can also send messages back to the peer manager for relay
39 2014-01-17 07:46:08 <wumpus> CodeShark: see https://github.com/bitcoin/bitcoin/issues/3465
40 2014-01-17 07:46:41 <CodeShark> yes, sipa and I have talked about this in the past quite a bit
41 2014-01-17 07:48:15 <wumpus> but personally I don't think it makes sense to do too much work to support altcoins
42 2014-01-17 07:49:02 <CodeShark> well, even considering how now we have two separate run modes - mainnet and testnet
43 2014-01-17 07:49:10 <wumpus> it's already easy enough to make a scamcoin, why would we make maintenance easier for them
44 2014-01-17 07:49:16 <CodeShark> could be subsumed into a single run mode just with different runtime configuration
45 2014-01-17 07:49:44 <wumpus> yes moving chain specific parameters to CChainParams makes sense, sure
46 2014-01-17 07:50:04 <CodeShark> but even having two separate instances of the params for main and test seems superfluous
47 2014-01-17 07:50:05 <wumpus> but making it possible to configure the network using a configuration file, I don't know
48 2014-01-17 07:50:22 <CodeShark> would be better to just have two datadirs, each with its own config file
49 2014-01-17 07:51:19 <CodeShark> we could even experiment with protocol rules to get empirical data
50 2014-01-17 07:51:37 <CodeShark> scamcoins are not the only application of this stuff :)
51 2014-01-17 07:51:57 <wumpus> non-scamcoins are going to involve large changes to the codebase anyway
52 2014-01-17 07:52:03 <wumpus> so can't be done with this generic approach
53 2014-01-17 07:52:12 <CodeShark> well, pretty soon we'll probably be moving over to something like ethereum anyhow
54 2014-01-17 07:52:19 <wumpus> 'we'?
55 2014-01-17 07:52:30 <CodeShark> well, the cryptocoin world
56 2014-01-17 07:52:49 <CodeShark> in other words, protocols that can support bitcoin as a special case
57 2014-01-17 07:53:08 <wumpus> I don't feel like having this discussion
58 2014-01-17 07:53:32 <CodeShark> call it whatevernet - sorry I mentioned one in particular
59 2014-01-17 07:54:36 <CodeShark> but perhaps this discussion is better for bitcoin-wizards :)
60 2014-01-17 07:55:14 <wumpus> more like #bitcoin if you want to argue that people are all going to move to an altcoin
61 2014-01-17 07:55:37 <CodeShark> that wasn't the argument - we can separate the value of a coin from the underlying protocol
62 2014-01-17 07:56:06 <CodeShark> we could still use bitcoins, but they could be encoded into a more general protocol's scripting language
63 2014-01-17 07:56:47 <Arnavion> It sounds like architecture astronomy
64 2014-01-17 07:57:27 <CodeShark> the more general protocol could also perhaps support greater security and much faster confirmation times
65 2014-01-17 07:58:04 <CodeShark> anyhow, I guess that topic is not for this channel
66 2014-01-17 07:58:04 <wumpus> Arnavion: yes, it's very hard to do software engineering for 'generic' stuff where you have to take into account everything that everyone can ever do
67 2014-01-17 07:59:46 <CodeShark> it'll take a lot of realworld experience with specific attempts, in an iterative process where each generation will build on the previous
68 2014-01-17 08:00:00 <CodeShark> bitcoin is extremely significant for being the first
69 2014-01-17 08:00:15 <wumpus> CodeShark: I agree that a more capable scripting language would be nice, certainly for all kinds of future experiments
70 2014-01-17 08:03:42 <CodeShark> the two main limitations of bitcoin's script are: 1) it is not Turing complete, 2) it cannot access nor update state information outside the immediate transaction, and other than the CHECKSIG opcodes, even outside of the script itself.
71 2014-01-17 08:05:05 <CodeShark> the next generation protocol will solve both these issues
72 2014-01-17 08:05:44 <wumpus> it's not sure that these are issues, or part of what made bitcoin actually practical :)
73 2014-01-17 08:06:16 <CodeShark> it made bitcoin practical in the sense that it restricted the domain and implementation complexity sufficiently so that it could actually get built and be demonstrated
74 2014-01-17 08:06:42 <wumpus> ...and still somehow understood (although it's already difficult for a lot of people)
75 2014-01-17 08:07:48 <CodeShark> but we'll eventually reach a point where very few people if any will understand all the details at all levels of abstraction - much like we've reached in the development of computers
76 2014-01-17 08:08:00 <CodeShark> the first computers were built by people who could grok the entirety of the system
77 2014-01-17 08:08:20 <CodeShark> but today's computers are so complicated with so many layers, very few people even understand one of them well :p
78 2014-01-17 08:08:24 <wumpus> possibly
79 2014-01-17 08:10:05 <wumpus> before we know it, we have malware scanners for your wallet, watch out for malicious transaction scripts, be sure to consult with your local cryptologist first
80 2014-01-17 08:10:13 <wumpus> :D
81 2014-01-17 08:10:29 <CodeShark> I think that's inevitable - the information arms race cannot be stopped
82 2014-01-17 08:11:06 <wumpus> hey, the nuclear arms race eventually stopped
83 2014-01-17 08:11:07 <CodeShark> a big price we pay for generally programmable computers is that they CAN be attacked by malware
84 2014-01-17 08:12:31 <CodeShark> the only reason the nuclear arms race stopped is because few applications beyond strategic deterrent could be found that don't involve killing a bunch of people
85 2014-01-17 08:12:33 <wumpus> right, which is why it can make sense in some scenarios to have a limited DSL instead of a full, turing complete language
86 2014-01-17 08:13:59 <CodeShark> a lot more research will be going into this in the next several years
87 2014-01-17 08:14:28 <CodeShark> technology doesn't take sides in ethical disputes, though
88 2014-01-17 08:14:33 <CodeShark> it serves all sides equally
89 2014-01-17 08:15:04 <wumpus> research is always good, but we should be careful on what we import into bitcoin, people have built a whole economy on top, they didn't sign in to make some battle of the scripts glitch contest :)
90 2014-01-17 08:15:43 <CodeShark> absolutely agreed, wumpus. It completely made sense to make bitcoin deliberately limited in some ways as we had no prior experience with this stuff
91 2014-01-17 08:16:23 <CodeShark> it's going to still take some time to fully understand all the implications
92 2014-01-17 08:16:52 <CodeShark> and yes, some people are going to inevitably get hurt as part of the process
93 2014-01-17 08:17:57 <wumpus> so it goes
94 2014-01-17 08:26:22 <Krellan> Ran bitcoin-qt recently. Empty gray window "No wallet has been loaded". Oh sh*t! I thought. Fortunately, it was just still loading at the time, and eventually loaded my wallet just fine.
95 2014-01-17 08:26:42 <wumpus> Krellan: what version?
96 2014-01-17 08:26:46 <Krellan> Good reminder to back up my wallet, though.
97 2014-01-17 08:27:02 <wumpus> Krellan: that must be some old version of master?
98 2014-01-17 08:27:10 <Krellan> It's from git recently, but not the latest
99 2014-01-17 08:27:45 <wumpus> 0.8.x doen't have the "No wallet has been loaded" dialog, and master shouldn't do that anymore (there was some problem with warnings during init showing the UI prematurely)
100 2014-01-17 08:28:34 <wumpus> but yes, backup your wallet
101 2014-01-17 08:29:11 <Krellan> Git hash be5d37c59757ac3b6deae1e3b238dcb2168207cb
102 2014-01-17 08:29:16 <Krellan> Yes, it's old. 22 November.
103 2014-01-17 08:29:28 <Krellan> Good reminder to upgrade it as well. Been remarkably stable, though.
104 2014-01-17 08:35:15 <wumpus> current master is also very stable, it has to be as we're nearing the 0.9 release
105 2014-01-17 08:37:42 <Krellan> Nice. Getting (gitting?) it now. Surprised no 0.8.x release in a while.
106 2014-01-17 08:39:52 <Krellan> question: is it becoming more possible to fully split bitcoin-qt (UI) from bitcoind (backend/network)?
107 2014-01-17 08:40:28 <Krellan> i'd love to keep my bitcoind running all the time, then run bitcoin-qt merely to get a friendly UI against my local bitcoind,
108 2014-01-17 08:40:45 <Krellan> instead of having to shut down bitcoind, open bitcoin-qt, make my transaction, close bitcoin-qt, restart bitcoind.
109 2014-01-17 08:49:57 <wumpus> Krellan: as it looks now we're going to split bitcoin-qt+wallet from bitcoind (P2P, blockchain storage, verification) first
110 2014-01-17 08:50:40 <wumpus> to isolate the wallet from the network process, and also so that it is possible to run multiple wallets against one blockchain daemon
111 2014-01-17 08:56:11 <wumpus> we only do 0.8.x (maintenenance) releases if there is a bug fix that needs to be backported, so it's good news if there isn't one in a while :)
112 2014-01-17 09:00:03 <Krellan> good to know - that's exactly the best idea i was hoping would be done - have bitcoin-qt own the wallet, and have bitcoind run the protocol/blockchain without needing wallet
113 2014-01-17 09:01:25 <Krellan> point wallets at bitcoind only when you want to use them
114 2014-01-17 09:47:56 <epscy> so will bitcoin-qt be an SPV wallet by default?
115 2014-01-17 09:48:09 <epscy> I'm interested to know how that will be handled
116 2014-01-17 10:25:01 <Emcy> epscy whats that? SPV mode finally?
117 2014-01-17 10:25:20 <Emcy> is that discussed on the develist? I can just catch up if so
118 2014-01-17 10:30:15 <epscy> Emcy: i'm not sure how imminent it is
119 2014-01-17 10:30:26 <epscy> they were discussing the split between node and wallet
120 2014-01-17 10:30:47 <epscy> which I assume means the wallet may need some sort of SPV mode
121 2014-01-17 10:30:57 <epscy> since it may not have a node to talk to
122 2014-01-17 10:31:06 <Emcy> great, even less nodes
123 2014-01-17 10:32:08 <Emcy> other people should do the modular shit (and they are). Bitcoin core is supposed to be a complete reference implementation of what bitcoin was envisioned to be
124 2014-01-17 10:33:02 <Emcy> that is, everything that bitcoin needs to be bitcoin running right there on the local machine, in front of your face, where you have sole dominion over it
125 2014-01-17 10:33:17 <niston> I'd suggest a service version of bitcoind for windows.
126 2014-01-17 10:33:24 <niston> that can run as NT service.
127 2014-01-17 10:34:04 <robonerd> are either of you core devs?
128 2014-01-17 10:35:25 <epscy> the split is inevitable i think
129 2014-01-17 10:36:10 <epscy> wallets are juicy targets, making their code simpler by removing uneeded functionality (for wallet operations) seems logical
130 2014-01-17 10:41:13 <Emcy> service/daemon mode would be great.
131 2014-01-17 10:41:39 <Emcy> sint the wallet code already fairly self contained inside the code already?
132 2014-01-17 10:48:14 <epscy> i think so
133 2014-01-17 10:48:57 <epscy> but having the wallet separate means you can do things like run it on a separate machine and have different firewall rules for the wallet and the node
134 2014-01-17 10:50:54 <Emcy> well that seems like a good idea
135 2014-01-17 10:50:56 <sipa> yup
136 2014-01-17 10:51:16 <sipa> i think pretty much everyone is in favor of some degree of separation
137 2014-01-17 10:51:25 <Emcy> but i know what will actually happen is that bitcoin core turns into electrum and the only nodes left are miners
138 2014-01-17 10:51:50 <sipa> whether that just means separating them into separate processes
139 2014-01-17 10:51:55 <Emcy> can you imagine my face when i learned people run public p2pool nodes for others to mine against?
140 2014-01-17 10:52:09 <sipa> it's inevitable
141 2014-01-17 10:52:38 <Emcy> why are we here then?
142 2014-01-17 10:53:06 <wumpus> bitcoin core will not 'turn into electrum', bitcoin core will always have the full node stuff as well, an electrum-like bitcoin-qt project will be a seperate project
143 2014-01-17 10:53:49 <Emcy> so this dev team is going to run another parellel project?
144 2014-01-17 10:53:57 <wumpus> yes, the goal is to split things up
145 2014-01-17 10:54:15 <wumpus> bitcoin core will really be the core, then the wallets and such will be seperate projects
146 2014-01-17 10:54:49 <Emcy> so were giving up wholesale on trying to make people run enforcement nodes
147 2014-01-17 10:54:49 <epscy> wumpus: i think he meant bitcoin core will turn into electrum server
148 2014-01-17 10:55:24 <wumpus> Emcy: just to not shove them through their throat in the name of running a wallet
149 2014-01-17 10:55:27 <epscy> Emcy: it could go either way, if running a node becomes easier maybe more people will do it
150 2014-01-17 10:56:03 <wumpus> a node will just be that, a node, and a wallet is a wallet, no need to have one monolithic thing, although you can obviously ship them together to lure people into running both
151 2014-01-17 10:56:31 <Emcy> wumpus i agree its been far too hard till now. But frankly why shouldnt people run a node if theyre going to run a wallet? Everyone has all these goddamn i7s lying around doing nothing
152 2014-01-17 10:56:54 <sipa> we can still ship them togethet
153 2014-01-17 10:56:58 <Emcy> we already know what happens if the attitude becomes "someone else will take care of it". Look around the world to see the result of that.
154 2014-01-17 10:57:02 <wumpus> yes they can still choose to do that
155 2014-01-17 10:57:06 <wumpus> it can even be the default
156 2014-01-17 10:57:18 <sipa> with the wallet starting a full node in the background
157 2014-01-17 10:57:22 <Emcy> sipa ok thats better
158 2014-01-17 10:57:39 <epscy> indeed, bear in mind that already bitcoind/qt isn't the recommended wallet on bitcoin.org
159 2014-01-17 10:58:06 <Emcy> epscy yes i dont like that, but i dont blame it either
160 2014-01-17 10:58:52 <epscy> Emcy: nodes that require 20GB+ and take hours (if not days) to sync are already only appealing to the more technically minded
161 2014-01-17 10:59:04 <wumpus> for most people running a full node is asking a bit too much, it's more something for enthousiasts that want to support the network, unnecessarily making people end up with a full node only results in complaints
162 2014-01-17 10:59:20 <Emcy> epscy those things dont matter if you can use it in the meantime
163 2014-01-17 10:59:30 <Emcy> the problem is right now you cant use it until its finished
164 2014-01-17 10:59:33 <epscy> it would be nice to see a push to get merchants to run a node, even if they use coinbase/bitpay for payments
165 2014-01-17 10:59:41 <epscy> not sure how you would incentivise that though
166 2014-01-17 10:59:45 <wumpus> yes, merchants and companies should certainly run nodes
167 2014-01-17 11:01:06 <epscy> i don't see a problem with node and wallet shipped together, and the node on by default, i also don't see a problem with making it easy to turn the node off
168 2014-01-17 11:01:32 <wumpus> but that's an advantage to splitting node and wallet: people can run a node because they want to help the network, completely aside from the wallet (which they may have at a web service, at bitpay, or whatever)
169 2014-01-17 11:02:03 <wumpus> also without putting anything at risk, as their wallet is not on the server they host the node on
170 2014-01-17 11:02:26 <epscy> ACTION nods
171 2014-01-17 11:02:34 <Emcy> epscy "easy" should mean "recompile the binary with NODEOFF flags" or something
172 2014-01-17 11:02:42 <wumpus> you could even hand out free/cheap boxes that run a full node, without hardly any user intervention
173 2014-01-17 11:02:51 <Emcy> if you stick a tickbox in there for it you can kiss the netowrk goodbye
174 2014-01-17 11:02:52 <epscy> Emcy: nah i disagree
175 2014-01-17 11:02:54 <wumpus> some simple web interface like routers...
176 2014-01-17 11:03:02 <sipa> Emcy: oh come on
177 2014-01-17 11:03:32 <wumpus> when there is no wallet or keys involved it all becomes alot less difficult and critical
178 2014-01-17 11:03:34 <Emcy> sipa do you not think?
179 2014-01-17 11:03:35 <sipa> Emcy: there are already 2 or 3 orders of magbitudes more b.i wallets than people running the reference client
180 2014-01-17 11:03:46 <Emcy> true
181 2014-01-17 11:04:08 <sipa> most of them wouldn't run a full nkde, even if it had the same wallet functionality and zerobresource usage
182 2014-01-17 11:04:13 <Emcy> and thered probably be even less runnig a client-node if it was too easy to opt out
183 2014-01-17 11:04:29 <wumpus> it *IS* easy to opt out already
184 2014-01-17 11:04:36 <wumpus> nothing we can do about that
185 2014-01-17 11:04:42 <wumpus> that train left a looong time ago
186 2014-01-17 11:04:46 <epscy> yup
187 2014-01-17 11:04:51 <Emcy> a quick and dirty comparison would be if taxes were wholly voluntary......enjoy your failed state
188 2014-01-17 11:05:04 <wumpus> sigh, I don't feel like that discussion
189 2014-01-17 11:05:23 <Emcy> its just a metaphor
190 2014-01-17 11:05:54 <wumpus> a very broken one, we can't hire a police force to force people to run full nodes :P
191 2014-01-17 11:05:57 <epscy> Emcy: the problem is we don't have a way to incentivise running nodes, wallet/node separation is kinda irrelevant to that I think
192 2014-01-17 11:06:18 <epscy> Emcy: it's not a new problem either
193 2014-01-17 11:06:48 <Emcy> bitcoin as envisioned was destined to fail then. It will morph into something else.
194 2014-01-17 11:07:01 <epscy> possibly
195 2014-01-17 11:07:36 <sipa> bitcoin as envisioned was everyone running a miner
196 2014-01-17 11:07:47 <sipa> of course the ideal needs to adapt
197 2014-01-17 11:07:59 <epscy> we should probably take this to #bitcoin if we want to continue, since it is likely more about politics and economics than anything else
198 2014-01-17 11:08:39 <Emcy> think im finished now
199 2014-01-17 11:09:09 <epscy> sipa: do you think satoshi knew about pooled mining when he first authored the white paper?, do you think he would be surprised to see the state of mining today?
200 2014-01-17 11:12:18 <sipa> epscy: i doubt that he foresaw that
201 2014-01-17 11:12:34 <epscy> interesting
202 2014-01-17 11:13:31 <epscy> tbh even if mining becomes incredibly centralized, I still think bitcoin will have value because it's a global protocol, the barrier to entry will still be lower than the alternatives
203 2014-01-17 11:13:56 <epscy> but i would be lying if i said it didn't concern me
204 2014-01-17 11:22:09 <Emcy> the only thing keeping miners in check is enforcement nodes
205 2014-01-17 11:22:18 <Emcy> (protocol wise)
206 2014-01-17 11:30:47 <wumpus> inform the masses, don't preach to the choir :)
207 2014-01-17 11:32:58 <Emcy> i try, when i can
208 2014-01-17 11:33:02 <Emcy> i dont exactly have a platform
209 2014-01-17 11:33:13 <wumpus> neither do I
210 2014-01-17 12:07:52 <fanquake> ;;blocks
211 2014-01-17 12:07:53 <gribble> 280978
212 2014-01-17 12:59:51 <TD> right. my bitcoin node should be reachable via hidden services as well now
213 2014-01-17 12:59:58 <TD> wish i wasn't too lazy to test it works :-)
214 2014-01-17 13:01:14 <michagogo> cloud|TD: What's the address?
215 2014-01-17 13:03:21 <TD> n5o5kf6ggofn37ne.onion
216 2014-01-17 13:04:24 <michagogo> cloud|{"addr" : "n5o5kf6ggofn37ne.onion","services" : "00000001","lastsend" : 1389963822,"lastrecv" : 1389963821,"bytessent" : 446,"bytesrecv" : 75292,"conntime" : 1389963816,"version" : 70002,"subver" : "/Satoshi:0.8.99/","inbound" : false,"startingheight" : 280981,"banscore" : 0}
217 2014-01-17 13:04:43 <TD> nice, thanks :)
218 2014-01-17 13:04:55 <TD> yep, i see it in the logs. great.
219 2014-01-17 13:05:08 <TD> and also in ARM
220 2014-01-17 13:05:15 <TD> i wonder how long it will take before nodes connect organically
221 2014-01-17 13:05:28 <michagogo> cloud|Not too long, probably
222 2014-01-17 13:05:45 <michagogo> cloud|I have 2-something incoming connections from localhost atm
223 2014-01-17 13:05:54 <michagogo> cloud|20-something*
224 2014-01-17 13:06:32 <michagogo> cloud|been running for ~15-20 hours
225 2014-01-17 13:14:51 <sipa> TD: i get tons of onion connections
226 2014-01-17 13:19:14 <michagogo> cloud|Same here
227 2014-01-17 13:24:09 <TD> huh
228 2014-01-17 13:24:11 <TD> interesting
229 2014-01-17 13:37:04 <tg0> Can BitcoinJS be used to sign transactions statelessly? Supply transactionhex, json inputs, and a private key corresponding to a public key in the redeemScript?
230 2014-01-17 13:40:34 <tg0> I'm having issues coming up with a universal way to pass transactions to clients to sign, it's hard to meet everyone's needs with this. An offline JS page would be great.
231 2014-01-17 13:40:46 <kjj_> bip10?
232 2014-01-17 13:55:38 <tg0> kjj_: I haven't read that too much, but guessing not everyone supports that either?
233 2014-01-17 13:58:51 <tg0> i'm generating unsigned multisignature transactions in bitcoind. I haven't gotten electrum to sign any of these yet, so that's got me thinking about just giving a js tool and they could just paste in the signed transaction.
234 2014-01-17 14:02:28 <sipa> that means you'd be trusting their browser with the private key?
235 2014-01-17 14:06:35 <tg0> yeah, it's not great. obviously not online, but then again, many won't bother with this, nor checking checksums
236 2014-01-17 14:07:25 <tg0> ideally the mpk would only be used for signing transactions, and not have access to funds
237 2014-01-17 14:47:14 <andytoshi> michagogo|cloud: would you like to try a testnet join?
238 2014-01-17 14:49:41 <andytoshi> michagogo|cloud: i have refreshed the windows build so there is a File->Settings... option to point the client at testnet
239 2014-01-17 14:49:52 <andytoshi> everyone: windows download link is http://download.wpsoftware.net/bitcoin/cj-windows.zip
240 2014-01-17 14:50:03 <andytoshi> source code is https://github.com/apoelstra/cj-client
241 2014-01-17 15:49:49 <shamoon> why are the first few bits of a block hash zero? i.e., 000000000002bd6090782457b3f614510407eb0426d48591b43416cfa3326ed9
242 2014-01-17 15:50:54 <gavinandresen> shamoon: https://en.bitcoin.it/wiki/Proof_of_work
243 2014-01-17 15:51:16 <shamoon> ohhhh
244 2014-01-17 15:51:23 <shamoon> so the block hash is what has to be less than the target
245 2014-01-17 15:51:29 <gavinandresen> yes
246 2014-01-17 15:52:00 <shamoon> thanks gavinandresen
247 2014-01-17 15:52:00 <shamoon> word
248 2014-01-17 16:34:28 <helo> (OT) having trouble finding gavin's blog post explaining the rationale for 5430 satoshi outputs being !isStandard(). looked through all of the foundation blog posts :/
249 2014-01-17 16:36:16 <helo> utxo bloat prevention is all i recall
250 2014-01-17 16:59:07 <gmaxwell> helo: it's not realy 54xx satoshi, it's a formula based on the minimum relay fee, attempting to approximate "very likely to cost more to spend than its worth"
251 2014-01-17 16:59:35 <gmaxwell> just with the current txn sizes and min relay fees it comes out to that amount. If you change the relay fee on your node it changes.
252 2014-01-17 17:00:51 <helo> ahh, right
253 2014-01-17 17:01:13 <Apocalyptic> I thought the relay fee was dropped
254 2014-01-17 17:07:09 <CodeShark> I just wish the relayers got to keep the fee rather than the miners :)
255 2014-01-17 17:07:26 <CodeShark> we've got really messed up incentives
256 2014-01-17 17:07:45 <sipa> yeah, i think that's the most important icnentive problem in bitcoin
257 2014-01-17 17:07:53 <sipa> but i know of no way - even theoretically - to solve it
258 2014-01-17 17:08:11 <phillipsjk> CodeShark, but what if there is more than 1 relay, who gets the fee?
259 2014-01-17 17:08:46 <phillipsjk> My solution: add token hash-power to my relay.
260 2014-01-17 17:08:54 <phillipsjk> Not really s solution though.
261 2014-01-17 17:09:32 <CodeShark> you need a proof-of-relay system
262 2014-01-17 17:09:53 <CodeShark> that doesn't add too much overhead
263 2014-01-17 17:10:17 <CodeShark> and there are also privacy issues
264 2014-01-17 17:10:54 <sipa> also, it would just mean you incentivize people to relay to miners directly...
265 2014-01-17 17:11:05 <sipa> to avoid relays from eating away the fee
266 2014-01-17 17:11:16 <CodeShark> for instance, if the script supported transactions where you can claim portions of the outputs if you can prove you relayed it
267 2014-01-17 17:11:44 <CodeShark> if the portions remain unclaimed, they go back to the originator
268 2014-01-17 17:11:48 <phillipsjk> or set up a virtual machine full of highbandwidth low latency "relays"
269 2014-01-17 17:11:49 <helo> this is the concern voiced by the microsoft researchers a while back, right?
270 2014-01-17 17:12:40 <CodeShark> sipa: miners don't really have incentive, then, to relay transactions they haven't mined
271 2014-01-17 17:14:11 <CodeShark> perhaps miners could also put up part of the relay fee
272 2014-01-17 17:14:23 <CodeShark> to avoid being bogged down with incoming connections
273 2014-01-17 17:18:20 <jcorgan> sipa: i'm having trouble replicating the WIF outputs of the BIP0032 test vectors
274 2014-01-17 17:18:56 <sipa> jcorgan: only the WIF outputs?
275 2014-01-17 17:19:02 <sipa> not xpub/xprv's?
276 2014-01-17 17:19:09 <jcorgan> right
277 2014-01-17 17:19:25 <jcorgan> it looks like the WIF outputs were created with a truncated secret key
278 2014-01-17 17:19:39 <sipa> truncated?
279 2014-01-17 17:19:51 <jcorgan> let me walk you through it
280 2014-01-17 17:20:01 <jcorgan> take test vector 1, key chain 'm'
281 2014-01-17 17:20:09 <sipa> ok
282 2014-01-17 17:20:23 <jcorgan> the published WIF is L52XzL2cMkHxqxBXRyEpnPQZGUs3uKiL3R11XbAdHigRzDozKZeW
283 2014-01-17 17:20:24 <sipa> what WIF key do you get?
284 2014-01-17 17:20:43 <jcorgan> i get 5KasyVKwgbH5VmDomdJdevZXRMMrbWcePkW17vxeg8daJWoeqHQ
285 2014-01-17 17:20:53 <sipa> you didn't add the compression flag
286 2014-01-17 17:21:08 <sipa> the WIF format is 0x80 [32 byte secret] 0x01
287 2014-01-17 17:21:15 <sipa> for compressed pubkeys
288 2014-01-17 17:21:20 <sipa> and BIP32 is compressed key only
289 2014-01-17 17:21:50 <jcorgan> ah, i guess you could call '32 byte secret' truncated :)
290 2014-01-17 17:22:25 <sipa> how so?
291 2014-01-17 17:22:48 <jcorgan> when i used http://gobittest.appspot.com/PrivateKey
292 2014-01-17 17:23:05 <jcorgan> to decode the published WIF, the resulting secret looked like a truncated version of the original
293 2014-01-17 17:23:26 <sipa> meh, another site that doesn't support compressed keys :(
294 2014-01-17 17:24:02 <sipa> they were introduced over 2 years ago now
295 2014-01-17 17:24:14 <jcorgan> so, is https://en.bitcoin.it/wiki/Wallet_import_format incomplete?
296 2014-01-17 17:24:33 <sipa> yes
297 2014-01-17 17:26:10 <jcorgan> is the only difference adding 0x01 to the end before calculating the checksum for appending?
298 2014-01-17 17:28:37 <sipa> yeah
299 2014-01-17 17:28:41 <sipa> feel free to update the wiki!
300 2014-01-17 17:28:45 <jcorgan> let me try that
301 2014-01-17 17:28:54 <Azra-el> hello. mind if i ask a question not related to bitcoin but about static compiling an altcoin? ^^
302 2014-01-17 17:29:21 <sipa> i'll answer if the question applies to bitcoin too
303 2014-01-17 17:30:31 <btcNeverSleeps> there's something I don't understand very well about Electrum and it's "12 words out of 1626, providing about 128 bits of entropy" (if I'm not mistaken). Why didn't it choose a bigger dictionnary, providing 256 bits of entropy? (for the user it would still just be a list of 12 words to write down) I know that 2^128 is "enough", but then we could also all use md5 instead SHA-256 etc.
304 2014-01-17 17:30:39 <jcorgan> sipa: we have a winner
305 2014-01-17 17:32:11 <Azra-el> i guess it should apply to every coin ... mainly how do i actually build a static version ... keep getting ld: cannot find -lgcc_s
306 2014-01-17 17:32:30 <sipa> btcNeverSleeps: that would require a dictionary of 2642243 words...
307 2014-01-17 17:34:23 <btcNeverSleeps> sipa: ooooh, gotcha
308 2014-01-17 17:34:54 <sipa> for 192 bits, it would require a 65536 word dictionary, which is already huge
309 2014-01-17 17:35:49 <btcNeverSleeps> and prone to mistakes from the user... I get it now : )
310 2014-01-17 17:35:54 <Azra-el> so im guessing it does not apply to bitcoin also :)
311 2014-01-17 17:36:29 <jcorgan> well, here is my progress so far on my BIP0032 address generator: http://pastebin.com/BjqxVzKL
312 2014-01-17 17:38:08 <btcNeverSleeps> another one about Electrum... I have my 12 words randomly generated by Electrum (and all differents) and now I generate an offline wallet for a friend: what is the probability that at least one of its 12 words is identical to one of my 12 words? Is it ((1626-12)/1626)^12 ? (which gives 8.5% and which I found quite high)
313 2014-01-17 17:38:49 <andytoshi> btcNeverSleeps: that looks right, and sounds about right
314 2014-01-17 17:39:06 <andytoshi> ^12 is a pretty violent operation
315 2014-01-17 17:39:17 <sipa> doesn't look right to me
316 2014-01-17 17:39:21 <btcNeverSleeps> I guess it I find this "quite high" for more or less the same reason the "birthday paradox" is called, well, a paradox : )
317 2014-01-17 17:39:28 <sipa> you forget the possibility that a given work may occur twice
318 2014-01-17 17:39:32 <sipa> *word
319 2014-01-17 17:39:49 <andytoshi> sipa: oh, that's right
320 2014-01-17 17:39:49 <btcNeverSleeps> sipa: I had 12 different words in my own wallet's 12-words seed
321 2014-01-17 17:39:56 <btcNeverSleeps> Wait
322 2014-01-17 17:39:59 <sipa> though i don't think it'll be much off if you do take that into account
323 2014-01-17 17:40:00 <andytoshi> btcNeverSleeps: also, you mean 1 minus what you wrote
324 2014-01-17 17:40:11 <btcNeverSleeps> I meant p = 1 - ((1626-12)/1626)^12
325 2014-01-17 17:40:30 <btcNeverSleeps> andytoshi: yup, 1 minus, wrote too fast
326 2014-01-17 17:41:03 <btcNeverSleeps> ain't it correct for "at least one identical word"?
327 2014-01-17 17:41:03 <sipa> if you assume both your and their passphrase can contain repeated words, it's 1-(1625/1626)^12
328 2014-01-17 17:41:07 <sipa> 0.73%
329 2014-01-17 17:41:30 <sipa> ah, no, that's the chance that the same word occurs at the same position
330 2014-01-17 17:41:35 <btcNeverSleeps> sipa: :)
331 2014-01-17 17:42:19 <andytoshi> sipa: i think if you want to take into account repeated works, you'll have to write an ugly sum
332 2014-01-17 17:42:58 <andytoshi> better to say, the "the probability that my friend will share a word, GIVEN that i have n unique words, is [(1626-n)/1626]^12"
333 2014-01-17 17:43:09 <andytoshi> s/better/way easier/
334 2014-01-17 17:43:13 <btcNeverSleeps> basically I'm asking because a friend came here so that I could generate him a fully offline wallet (from a computer with no hard-disk and using a Linux boot CD, etc.), an old offline printer (no WiFi) and all that... So it was feeling all secure and then *poof*: one of his word was the same as one of mine, so we started running the math and weren't too sure ^ ^
335 2014-01-17 17:43:41 <sipa> ok, degrade the problem
336 2014-01-17 17:43:45 <btcNeverSleeps> andytoshi: now you forgot the one minus right?
337 2014-01-17 17:43:46 <sipa> and say we're only using 2 words
338 2014-01-17 17:43:49 <andytoshi> btcNeverSleeps: yes :)
339 2014-01-17 17:43:56 <sipa> in the dicitonary
340 2014-01-17 17:44:01 <sipa> and use 128 words instead of 12
341 2014-01-17 17:44:10 <sipa> the chance of a word being repeated now is 100%
342 2014-01-17 17:44:16 <sipa> big deal?
343 2014-01-17 17:44:48 <Azra-el> my passwords often contain letters found in other people's passwords
344 2014-01-17 17:44:57 <btcNeverSleeps> Azra-el: point taken : )
345 2014-01-17 17:45:13 <Azra-el> as long as the rest of the letters arent the same i guess im ok :)
346 2014-01-17 17:45:43 <btcNeverSleeps> and there's more than 50% two people out of 23 in a classroom have their birthday the same day... It's still called a "paradox" for a reason :)
347 2014-01-17 17:45:45 <andytoshi> oh, i thought this was a purely academic question :} yes, it's silly
348 2014-01-17 17:46:41 <btcNeverSleeps> well we got into a friendly argument about the math behind it... I wouldn't have checked if it happened to have had 12 entirely different words.
349 2014-01-17 17:46:49 <Azra-el> i think you need to def: paradox btcNeverSleeps
350 2014-01-17 17:47:13 <btcNeverSleeps> Azra-el: I think the person who coined the term "Birthday paradox" should ;)
351 2014-01-17 17:48:34 <Azra-el> well not to be anal but yeah maybe they should.... i know what you're refering and afaik the def is "A paradox is a statement that apparently contradicts itself and yet might be true"
352 2014-01-17 17:58:26 <jgarzik> gents,
353 2014-01-17 17:58:30 <btcNeverSleeps> noobish question: when you receive bitcoins to one of your public adress, do you always have enough infos to send what you received back to the sender (ignoring fees)? I mean: do you have always have one public adress (or multiple ones) from which the coins came that you can then use as recipients should you want to send the coins back?
354 2014-01-17 17:58:39 <jgarzik> BitPay would like 3-of-5 multisig to be standard
355 2014-01-17 17:58:46 <jgarzik> <vendor hat: on>
356 2014-01-17 17:59:00 <jgarzik> any objections? data spam?
357 2014-01-17 17:59:03 <sipa> btcNeverSleeps: no
358 2014-01-17 17:59:12 <kjj_> there is no sender
359 2014-01-17 17:59:19 <jgarzik> current relay standard is X-of-3, maximum
360 2014-01-17 17:59:19 <sipa> btcNeverSleeps: you cannot send coins back in a reliable way, without asking for an address from the sender
361 2014-01-17 18:00:43 <sipa> jgarzik: compromise: enable X-of-Y, where Y is at most 5 and X is at most 3?
362 2014-01-17 18:00:56 <lechuga__> interesting
363 2014-01-17 18:01:00 <lechuga__> what is bitpay up to :)
364 2014-01-17 18:01:02 <sipa> jgarzik: that has the same resource requirements as 3-of-3
365 2014-01-17 18:01:26 <kjj> what abuse is the nonstandardness of x-of-y preventing anyway?
366 2014-01-17 18:01:34 <jgarzik> sipa, interesting thought
367 2014-01-17 18:01:43 <kjj> people padding data into their spare of-y slots?
368 2014-01-17 18:01:52 <jgarzik> kjj, 1-of-100, store 99 data x 32 bytes
369 2014-01-17 18:01:57 <jgarzik> and one valid key
370 2014-01-17 18:01:58 <sipa> (i'm not saying that X and Y need these limits from my point of view, but it's an argument that can help convince others)
371 2014-01-17 18:02:19 <sipa> oh wait no
372 2014-01-17 18:02:29 <sipa> the scriptSig needs all pubkeys
373 2014-01-17 18:02:32 <sipa> hrmms
374 2014-01-17 18:02:46 <lechuga__> wouldnt the scriptPubKey have all of the pubkeys
375 2014-01-17 18:03:04 <sipa> well, in P2SH the scriptSig
376 2014-01-17 18:03:06 <sipa> but indeed
377 2014-01-17 18:03:10 <jgarzik> this is P2SH
378 2014-01-17 18:03:12 <lechuga__> ic
379 2014-01-17 18:03:13 <jgarzik> we like P2SH :)
380 2014-01-17 18:03:14 <kjj> how about (x+y)<=8
381 2014-01-17 18:03:48 <jgarzik> before re-reading, I was thinking that what kjj just said was what sipa was thinking
382 2014-01-17 18:04:22 <jgarzik> something where Y is bounded by X
383 2014-01-17 18:04:37 <lechuga__> x > y makes no sense
384 2014-01-17 18:04:48 <kjj> a sig is roughly the same size as a pubkey, so sizewise x+y is the important part.
385 2014-01-17 18:05:10 <kjj> I would argue that checking the sigs is "free" at the moment too
386 2014-01-17 18:06:43 <waxwing> x of y has a lot of applications. tx fee ratcheted to size is the real issue here, no?
387 2014-01-17 18:08:17 <lechuga__> did any1 notice the realitykeys announcement?
388 2014-01-17 18:08:56 <lechuga__> i wonder if they get bragging rights for first oracle
389 2014-01-17 18:11:44 <jgarzik> lechuga__, I tweeted/FB'd/G+'d about Reality Keys :)
390 2014-01-17 18:11:57 <jgarzik> good stuff. glad to see these sorts of applications.
391 2014-01-17 18:13:05 <petertodd> jgarzik: P2SH doesn't have n-of-m limits btw
392 2014-01-17 18:13:15 <petertodd> jgarzik: only bare CHECKMULTISIG does
393 2014-01-17 18:13:31 <lechuga__> yeah the BIP says it can accomodate 22+ sigs?
394 2014-01-17 18:13:35 <jgarzik> petertodd, really? I'll have to double check that.
395 2014-01-17 18:13:47 <jgarzik> That doesn't match my memory.
396 2014-01-17 18:13:48 <lechuga__> i havent processed how that scriptSig works tho
397 2014-01-17 18:13:52 <lechuga__> re: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
398 2014-01-17 18:13:56 <lechuga__> grep for "+22"
399 2014-01-17 18:14:14 <petertodd> lechuga__: no, CHECKMULTISIG maxes out at 20, and because P2SH is limited by the max size of a PUSHDATA it can only do 15 compressed pubkeys
400 2014-01-17 18:14:35 <petertodd> jgarzik: follow the IsStandardTxInput or whatever it was called again code - nothing actually checks it
401 2014-01-17 18:14:50 <lechuga__> IsStandard() it hink
402 2014-01-17 18:15:10 <petertodd> lechuga__: oh, that's talked about signature operations, not signatures
403 2014-01-17 18:15:21 <lechuga__> ah
404 2014-01-17 18:15:22 <petertodd> lechuga__: *talking
405 2014-01-17 18:15:40 <lechuga__> its still not clear to me exactly what it means
406 2014-01-17 18:15:50 <lechuga__> like its obvious how the +3 operations one works
407 2014-01-17 18:16:11 <jgarzik> petertodd, uh, scriptSig size check is right up front
408 2014-01-17 18:16:46 <petertodd> lechuga__: that's an interesting edge case, because within a p2sh the sigops of a script is evaluated differently - if the CHECKMULTISIG op has a non-numerical anything behind it it counts as the usual 20 sigops, but if it is a push-small-number it counts the actual signatures as the sigops
409 2014-01-17 18:16:51 <petertodd> jgarzik: heh, how much do you want to bet?
410 2014-01-17 18:17:16 <jgarzik> }
411 2014-01-17 18:17:16 <jgarzik> if (txin.scriptSig.size() > 500) {
412 2014-01-17 18:17:16 <jgarzik> reason = "scriptsig-size";
413 2014-01-17 18:17:16 <jgarzik> return false;
414 2014-01-17 18:17:33 <jgarzik> petertodd, nothing, I just pasted
415 2014-01-17 18:18:05 <petertodd> jgarzik: right, but it *doesn't* check how many pubkeys are in a CHECKMULTISIG in a P2SH, unlike the non-P2SH case
416 2014-01-17 18:18:22 <petertodd> jgarzik: in other words with P2SH bitpays 3-of-5 requirement can be met
417 2014-01-17 18:18:24 <jgarzik> petertodd, sure it does... indirectly ;p
418 2014-01-17 18:18:41 <petertodd> jgarzik: point is, 3-of-5 checkmultisig in a P2SH is standard
419 2014-01-17 18:19:11 <petertodd> jgarzik: n-of-15 can even be spent
420 2014-01-17 18:19:27 <lechuga__> so you can do scriptSig: <sig1> <sig2> <sig3> 3 <key1> ... <key5> 5 OP_CHECKMULTISIG ?
421 2014-01-17 18:19:45 <jgarzik> petertodd, with this size limit, no, it effectively is not
422 2014-01-17 18:20:08 <lechuga__> trying to understand how youd actually construct a 3-of-5 scriptsig
423 2014-01-17 18:20:52 <petertodd> jgarzik: ok, so 5 compressed keys and 3 signatures: 5*34 + 1 + 73*3 + 3 = 393 bytes
424 2014-01-17 18:21:45 <lechuga__> guess i forgot op_0
425 2014-01-17 18:22:06 <jgarzik> petertodd, interesting; I came up with 565
426 2014-01-17 18:24:40 <petertodd> jgarzik: here, 3c2a2893c473bfc78354436bd698f7a6f64bdb623177ecf8e246aeee7c70b53d spends 38c06dbb642831f75949079615b5ca8889c1bd057338d21c6cab0bd5c9d52033
427 2014-01-17 18:26:08 <lechuga__> oh wow i totally misunderstood p2sh for multisig
428 2014-01-17 18:26:31 <sipa> wait, what? p2sh multisig doesn't check standardness of the spending script?
429 2014-01-17 18:26:33 <jcorgan> sipa: to clarify my understanding of WIF, for secret keys to associated with an uncompressed pubkey, with raw format is '\x80'+secret before encoding, and if the secret key is to be associated with a compressed pubkey, you also add a '\x01' to the raw format before encoding. (perhaps 'associated' is the wrong term)
430 2014-01-17 18:26:43 <sipa> jcorgan: correct
431 2014-01-17 18:26:45 <petertodd> jgarzik: now, having said that, for stealth addresses one possible way to implement them would be to put the ephemereal pubkey in a bare checkmultisig
432 2014-01-17 18:26:47 <lechuga__> sipa: it's a diff definition of standradr
433 2014-01-17 18:26:51 <lechuga__> where standard = only push ops
434 2014-01-17 18:27:03 <lechuga__> at least given my read of the code
435 2014-01-17 18:27:05 <sipa> petertodd: ewwww
436 2014-01-17 18:27:21 <jcorgan> thanks
437 2014-01-17 18:27:29 <petertodd> sipa: it checks everything but what n and m of the n-of-m it is
438 2014-01-17 18:27:32 <sipa> lechuga__: standard p2sh scriptsig = push only + standard embedded pubkey script
439 2014-01-17 18:28:18 <petertodd> sipa: meh, means they look exactly like any other checkmultisig - means a SPV client could query for matching txouts rather than transactions containing specified txouts
440 2014-01-17 18:28:44 <sipa> petertodd: my ewww does not preclude it from being the best technical solution :)
441 2014-01-17 18:28:46 <petertodd> sipa: if we wind up in a model where SPV clients only get txouts that'd useful - ie with committed UTXO or similar schemes
442 2014-01-17 18:28:52 <petertodd> sipa: heh, well...
443 2014-01-17 18:29:12 <petertodd> sipa: alternative for that kind of scheme is jgarzik's OP_DROP data...
444 2014-01-17 18:41:27 <lechuga__> i wonder if a decentralized oracle could make sense
445 2014-01-17 18:41:41 <lechuga__> given an oracle is by definition a trusted 3rd party
446 2014-01-17 18:42:30 <petertodd> here's a spend of a 1-of-12 p2sh: 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
447 2014-01-17 18:42:56 <petertodd> that's a 411 byte script sig, the max you can do in the 500 byte limit
448 2014-01-17 18:43:17 <lechuga__> hmm why doesnt that txn show up in blockexplorer
449 2014-01-17 18:43:58 <petertodd> lechuga__: it will once it confirms
450 2014-01-17 18:44:06 <lechuga__> o u just made it :)
451 2014-01-17 18:44:15 <petertodd> lechuga__: blockexplorer and blockchian.info both ignore p2sh anything
452 2014-01-17 18:44:37 <jgarzik> lechuga__, just multiple independent oracles, answering the same question
453 2014-01-17 18:44:38 <lechuga__> oh really?
454 2014-01-17 18:45:15 <lechuga__> jgarzik: but what about the 3rd party's signature?
455 2014-01-17 18:45:35 <lechuga__> how can i disperse the signing material securely among decentralized oracles
456 2014-01-17 18:46:19 <lechuga__> actually
457 2014-01-17 18:46:26 <sipa> it can be centralized but relatively trustless (by making the oracle aware of who you are and testable)
458 2014-01-17 18:46:30 <sipa> *unaware
459 2014-01-17 18:47:00 <jgarzik> petertodd, 1-of-12 is less interesting than, say, 5 of 7 or 3 of 5
460 2014-01-17 18:47:45 <petertodd> jgarzik: heh, well I can do all those too if you want :)
461 2014-01-17 18:51:59 <lechuga__> so is it true to say the serialized script in the p2sh scripSig can be compeltely nonstandard?
462 2014-01-17 18:52:39 <sipa> no
463 2014-01-17 18:52:47 <sipa> apparently there's only one check missing from it
464 2014-01-17 18:53:26 <lechuga__> i cant find the check for standardness on the deserialized script in VerifyScript
465 2014-01-17 18:53:54 <sipa> checking for standardness != checking for validity
466 2014-01-17 18:54:01 <sipa> a script can be either or both
467 2014-01-17 18:56:10 <lechuga__> one check missing?
468 2014-01-17 18:59:45 <lechuga__> still confused, i dont see any standardness check on the serialized script in p2sh scriptsig
469 2014-01-17 18:59:49 <lechuga__> im probably being dense though
470 2014-01-17 19:02:19 <lechuga__> scriptSig: [signature] {[foo] OP_DROP [bar] OP_DROP [blah] OP_DROP}
471 2014-01-17 19:02:29 <lechuga__> that looks like it'd be legal to me
472 2014-01-17 19:02:57 <lechuga__> pointless but legal
473 2014-01-17 19:02:57 <sipa> VerifyScript has nothing to do with standardness
474 2014-01-17 19:03:05 <sipa> it checks whether the script evaluates to true
475 2014-01-17 19:03:10 <sipa> which is only done at spending time
476 2014-01-17 19:03:18 <lechuga__> ok well IsStandardTx
477 2014-01-17 19:03:22 <sipa> standardness is enforced entirely differently
478 2014-01-17 19:03:24 <lechuga__> i still dont see a check on the serialized script there
479 2014-01-17 19:03:45 <lechuga__> i only see a standardness check on scriptPubKey
480 2014-01-17 19:04:24 <sipa> see AreInputsStandard
481 2014-01-17 19:06:02 <lechuga__> ok i see that it validates that the scriptSig only contains push ops
482 2014-01-17 19:06:22 <lechuga__> but it doesnt deserialize the serizlied script for p2sh scriptSig and do any check on that afaict
483 2014-01-17 19:06:34 <sipa> indeed
484 2014-01-17 19:06:43 <petertodd> lechuga__: no it does, it checks that the inner scriptPubKey is a IsStandard() type
485 2014-01-17 19:07:09 <petertodd> lechuga__: the thing is that it doesn't use IsStandard() for that, it actually just checks via some other function
486 2014-01-17 19:07:22 <lechuga__> ok
487 2014-01-17 19:07:26 <petertodd> lechuga__: (forget the name off the top of my head) and checks that the number of pushdata arguments is correct
488 2014-01-17 19:07:32 <lechuga__> so: scriptSig: [signature] {[foo] OP_DROP [bar] OP_DROP [blah] OP_DROP}
489 2014-01-17 19:07:35 <lechuga__> is illegal?
490 2014-01-17 19:07:42 <sipa> no, but non-standard
491 2014-01-17 19:07:50 <lechuga__> and thus wont be relayed
492 2014-01-17 19:07:52 <lechuga__> ok
493 2014-01-17 19:07:55 <sipa> indeed
494 2014-01-17 19:08:06 <lechuga__> i should try it and set a breakpoint and see exactly how
495 2014-01-17 19:08:08 <petertodd> lechuga__: for instance while it checks that a CHECKMULTISIG has *a* extra PUSHDATA to get around the too-many-dropped bug, it doesn't actually check that the extra pushdata is a null
496 2014-01-17 19:09:20 <lechuga__> ah
497 2014-01-17 19:09:27 <lechuga__> so OP_0 could be anything at all
498 2014-01-17 19:09:30 <petertodd> exactly
499 2014-01-17 19:09:59 <petertodd> source of tx mutability too, so that needs fixing
500 2014-01-17 19:10:21 <lechuga__> so is 3-of-5 specially standard iff it appears in a serialized scriptSig for p2sh?
501 2014-01-17 19:10:41 <petertodd> yup
502 2014-01-17 19:10:56 <lechuga__> and there are no hard x-of-y limits only implicit limit on size?
503 2014-01-17 19:11:01 <petertodd> yup
504 2014-01-17 19:11:04 <lechuga__> phew ok
505 2014-01-17 19:11:08 <lechuga__> :)
506 2014-01-17 19:11:11 <petertodd> hence my 1-of-12 proof-of-existence :)
507 2014-01-17 19:11:50 <lechuga__> learning is fun
508 2014-01-17 19:12:07 <petertodd> lechuga__: you can learn some more and fix the OP_0 thing for us...
509 2014-01-17 19:12:37 <lechuga__> i could take a look
510 2014-01-17 19:12:44 <petertodd> lechuga__: thanks
511 2014-01-17 19:12:46 <lechuga__> np
512 2014-01-17 19:12:53 <lechuga__> thank you guys
513 2014-01-17 19:12:57 <lechuga__> id be lost without u
514 2014-01-17 19:13:12 <lechuga__> playign catch-up when everyone else has had 2+ years to soak all of this stuff in is rough
515 2014-01-17 19:13:37 <petertodd> lechuga__: np problem, one of the best ways to learn something thoroughly is to teach it to others :)
516 2014-01-17 19:14:33 <nickler> what is a good way to get testnet coins? Both tpfaucet.appspot.com and faucet.xeno-genesis.com give me some kind of HTTP/API error.
517 2014-01-17 19:20:59 <EasyAt> tank
518 2014-01-17 19:21:03 <lechuga__> another gap in my understanding is in ecc itself
519 2014-01-17 19:21:11 <lechuga__> i read http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography which is great and all
520 2014-01-17 19:21:15 <lechuga__> but i want a bit more detail
521 2014-01-17 19:21:52 <lechuga__> can anyone recommend a good article a non-crypto expert could read which would help build upon the basic understanding
522 2014-01-17 19:25:05 <nickler> lechuga__: I am a cryptography newbie, but http://daaproject.googlecode.com/svn/trunk/%E8%B5%84%E6%96%99/Guide%20to%20Elliptic%20Curve%20Cryptography%20-%202004%20-%20(By%20Laxxuss).pdf was a good introduction for me. Found this by searching for "elliptic curve cryptography introduction" on google scholar.
523 2014-01-17 19:27:23 <lechuga__> am i crazy or is this in japanese
524 2014-01-17 19:28:36 <nickler> either i am crazy or this is in english
525 2014-01-17 19:29:15 <lechuga__> nm
526 2014-01-17 19:29:16 <lechuga__> i was crazy
527 2014-01-17 19:29:19 <lechuga__> thx :)
528 2014-01-17 19:29:58 <lechuga__> this looks good
529 2014-01-17 19:32:59 <twizt> hey
530 2014-01-17 19:33:08 <twizt> does lowercase uppercase matter for a bitcoin address?
531 2014-01-17 19:33:12 <gmaxwell> yes
532 2014-01-17 19:33:21 <twizt> so its a different address?
533 2014-01-17 19:33:29 <twizt> 1387489sdf
534 2014-01-17 19:33:32 <twizt> 1387489SDf
535 2014-01-17 19:33:34 <twizt> = different?
536 2014-01-17 19:34:23 <gmaxwell> Yes, the case matters.
537 2014-01-17 19:34:34 <gmaxwell> though a simple change like that is almost never a valid address.
538 2014-01-17 19:34:48 <twizt> gotcha