1 2012-11-21 00:08:04 <Icoin> hi guys i would like to inform you about a legal development in switzerland https://bitcointalk.org/index.php?topic=127016.msg1348456#msg1348456
2 2012-11-21 00:09:08 <D34TH> i want dnd ported to xbox
3 2012-11-21 00:09:09 <D34TH> D:
4 2012-11-21 00:37:58 <helo> does this make sense? reddit.com/r/Bitcoin/comments/13jj0d/in_favor_of_not_increasing_the_block_size/
5 2012-11-21 00:46:21 <maaku> helo: yes, developing a system for moving more transactions off-chain (using opentxns?) is more prudent than lifting block size limits
6 2012-11-21 00:48:58 <helo> bah, already downvoted lol
7 2012-11-21 00:57:50 <jgarzik> helo: commented
8 2012-11-21 00:58:03 <jgarzik> A lot of people do not understand how fundamental block size is to bitcoin economics.
9 2012-11-21 01:00:27 <kjj_> I guess that really remains to be seen. I'd put it a rung or two lower than the coin limit
10 2012-11-21 01:01:13 <kjj_> but still high enough that you'd want a much better reason than "because we can" to change it
11 2012-11-21 01:02:03 <fiesh> I don't fully understand the argument behind keeping the block size constant. Computing power, storage space, and bandwidth grow exponentially, so why would it be bad to have the block size grow exponentially too?
12 2012-11-21 01:02:43 <kjj_> fees must support the miners. larger blocks reduces the competition for block space, resulting in lower fees
13 2012-11-21 01:03:13 <fiesh> can you explain that?
14 2012-11-21 01:03:27 <kjj_> which part is causing your trouble?
15 2012-11-21 01:03:40 <fiesh> how do larger blocks reduce competition?
16 2012-11-21 01:04:38 <kjj_> transactions take space. if you and all of the world are hoping to make it into the next block, you have to outbid most of them to get in
17 2012-11-21 01:04:59 <kjj_> if you bid too low (with your fees), your transaction won't go in, at least not right away
18 2012-11-21 01:05:45 <jgarzik> w00t
19 2012-11-21 01:05:57 <jgarzik> picocoin/libccoin passed first 60 tests of script_valid.json
20 2012-11-21 01:06:04 <fiesh> yes but assuming an exponential growth of the bitcoin network, the number of transactions should grow exponentially, so having the block size grow exponentially would mean the fees stay fixed, which is exactly desirable I think
21 2012-11-21 01:07:20 <fiesh> likewise I do not see how, as written on reddit, larger blocks would mean fewer full nodes exist, because of the hardware growth mentioned above
22 2012-11-21 01:08:11 <fiesh> keeping the block chain size grow linearly does not seem meaningful to me here
23 2012-11-21 01:08:23 <kjj_> currently, fees won't buy you a cup of coffee, much less pay for the electricity to do quadrillions of hashes per second
24 2012-11-21 01:09:14 <fiesh> true, which means that the blocks are too large already, but it doesn't say anything about how they should grow
25 2012-11-21 01:09:48 <kjj_> and I'm saying that it is VERY much premature to be making claims about what the block size "should" be
26 2012-11-21 01:10:54 <fiesh> I don't think conjecturing on its growth rate is premature, telling absolute numbers on the other hand definitely is. and besides, it's the reddit post that makes claims about when the block size should be, in exact numbers
27 2012-11-21 01:11:23 <kjj_> meh. fuck reddit
28 2012-11-21 01:11:30 <fiesh> hehe agreed
29 2012-11-21 01:26:26 <jgarzik> w00t
30 2012-11-21 01:26:38 <jgarzik> passes all script_valid.json tests, once a test bug was fixed
31 2012-11-21 01:26:45 <jgarzik> passes 191 script_invalid.json tests
32 2012-11-21 01:28:28 <jgarzik> ah hah. P2SH.
33 2012-11-21 02:51:53 <jgarzik> sipa: looking at (flags & SCRIPT_VERIFY_P2SH) in VerifyScript()
34 2012-11-21 02:52:07 <jgarzik> sipa: P2SH checking references stackCopy.back()
35 2012-11-21 02:52:38 <jgarzik> sipa: stackCopy is created after the first EvalScript() call, but stack.empty() is checked after the second EvalScript() call
36 2012-11-21 02:53:03 <jgarzik> sipa: are we guaranteed that stackCopy.empty() == false, at the time of P2SH verification?
37 2012-11-21 02:53:30 <jgarzik> EDIT: sipa: P2SH directly references stackCopy.back()
38 2012-11-21 05:23:10 <nat> hy everybody !
39 2012-11-21 05:23:41 <nat> why can i put money on bitcoint ??
40 2012-11-21 05:28:17 <weex> what?
41 2012-11-21 05:31:46 <nat> hy ??
42 2012-11-21 05:31:59 <nat> [07:23] <nat> why can i put money on bitcoint ??
43 2012-11-21 05:32:09 <nat> why can i put money on bitcoint ??
44 2012-11-21 05:32:11 <ThomasV> lol
45 2012-11-21 05:32:17 <Cusipzzz> O.o
46 2012-11-21 05:32:26 <nat> yes as you say
47 2012-11-21 05:32:54 <nat> ?? any answer ??
48 2012-11-21 05:33:02 <ThomasV> go to mtgox.com
49 2012-11-21 06:10:02 <sipa> jgarzik: i didn't write that code, just switcjed it from using a bool to using a flag
50 2012-11-21 06:13:38 <jgarzik> sipa: I guess P2SH is gavincode?
51 2012-11-21 06:19:13 <weex> is the block height of the genesis block 0 or 1?
52 2012-11-21 06:19:33 <sipa> weex: 0
53 2012-11-21 06:19:38 <sipa> jgarzik: indeed
54 2012-11-21 06:19:49 <weex> thx sipa
55 2012-11-21 07:10:24 <robbak> Are we going to get a github branch and/or tag for 0.7.2?
56 2012-11-21 07:20:54 <maaku> robbak: bitcoin versions are always tagged vX.Y.Z
57 2012-11-21 07:21:47 <sipa> robbak: yes, soon, i think
58 2012-11-21 07:37:24 <Luke-Jr> robbak: it's already there, but not tagged yet
59 2012-11-21 07:37:29 <Luke-Jr> I think we're waiting for one more fix
60 2012-11-21 07:38:12 <Luke-Jr> http://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable/trees/0.7.x
61 2012-11-21 07:39:44 <sipa> Luke-Jr: which one?
62 2012-11-21 07:40:25 <Luke-Jr> sipa: 0.7.x branch
63 2012-11-21 07:40:54 <sipa> no, one more fix: which one?
64 2012-11-21 07:41:21 <Luke-Jr> jgarzik: mind if I forward your email to Tony Gallippi (BitPay)? he just bought Bitcoin Magazine (which Matonis contributes to
65 2012-11-21 07:41:38 <Luke-Jr> sipa: oh, wumpus mentioned #2024
66 2012-11-21 07:41:46 <Luke-Jr> Diapolo too
67 2012-11-21 07:44:02 <jgarzik> Luke-Jr: sure
68 2012-11-21 07:44:05 <sipa> oh, that one; fDbEnvInit not being initialized is indeed a bug
69 2012-11-21 07:44:44 <robbak> Luke-Jr: is this one going to be released from gitorious, not github, then?
70 2012-11-21 07:45:08 <sipa> robbak: we'll probably tag it on github too
71 2012-11-21 07:45:11 <Luke-Jr> robbak: stable/backport releases are always from gitorious, but often the tags are copied to the github repo
72 2012-11-21 07:45:33 <Luke-Jr> github is mainly for master/new-stable
73 2012-11-21 07:45:50 <Luke-Jr> eg, 0.8 is next
74 2012-11-21 07:49:15 <sipa> s
75 2012-11-21 07:51:49 <Luke-Jr> t
76 2012-11-21 07:51:51 <Luke-Jr> O.o
77 2012-11-21 08:03:38 <abrkn> anyone have some testnet i can have? so lonely on the testnet-in-a-box
78 2012-11-21 08:05:58 <SomeoneWeird> can't use the normal testnet?
79 2012-11-21 08:06:48 <abrkn> SomeoneWeird: right, that's what i want to use, but need some coins
80 2012-11-21 08:07:15 <abrkn> SomeoneWeird: generating would kill my laptop
81 2012-11-21 08:07:44 <SomeoneWeird> heh
82 2012-11-21 08:08:11 <abrkn> SomeoneWeird: i see you are in the node.js channel. did you see my offer on the forum? 100 btc to have brainwallet ported
83 2012-11-21 08:08:27 <SomeoneWeird> to node?
84 2012-11-21 08:08:33 <abrkn> yes
85 2012-11-21 08:08:45 <SomeoneWeird> hmmmmm
86 2012-11-21 08:09:18 <SomeoneWeird> you mean just clientside functions?
87 2012-11-21 08:09:45 <abrkn> i mean that if you can do something on brainwallet now, the node lib must also be able to do it
88 2012-11-21 08:10:06 <SomeoneWeird> right, so you just want a lib to generate bitcoin stuff?
89 2012-11-21 08:10:07 <SomeoneWeird> lol
90 2012-11-21 08:10:37 <abrkn> yes
91 2012-11-21 08:11:16 <jgarzik> abrkn: Do you need some testnet3 coins?
92 2012-11-21 08:11:32 <abrkn> jgarzik: that'd be great, mwbQ9LRrWtW1gaXNyReKmdJ5M7FjzBHeKr
93 2012-11-21 08:12:29 <abrkn> jgarzik: tyvm
94 2012-11-21 08:12:40 <jgarzik> cheers
95 2012-11-21 08:13:57 <abrkn> SomeoneWeird: i think it pretty much just generates (chains of) addresses from passphrases, signs/verifies messages, encodes/decodes raw trans
96 2012-11-21 08:14:06 <SomeoneWeird> yeah
97 2012-11-21 08:15:22 <abrkn> i'd love to do it myself, but crypto and bitmath has always been something that i don't give a shit about
98 2012-11-21 08:17:59 <SomeoneWeird> yeah
99 2012-11-21 08:20:54 <abrkn> maybe it'd be more reasonable to do it in parts. one project for chain address generation and move from there
100 2012-11-21 08:26:49 <sipa> Arnavion: why do you want that?
101 2012-11-21 08:26:55 <sipa> eh, abrkn
102 2012-11-21 08:27:34 <abrkn> sipa: to create addresses in node.js
103 2012-11-21 08:27:48 <SomeoneWeird> have a looked @ bitcoinjs? lol
104 2012-11-21 08:28:01 <t7> abrkn: there is a node.js client
105 2012-11-21 08:28:08 <t7> maybe that has address generation
106 2012-11-21 08:28:11 <sipa> yes, bitcoinjs
107 2012-11-21 08:28:26 <t7> also dont use node.js . good day
108 2012-11-21 08:28:36 <SomeoneWeird> t7, gtfo
109 2012-11-21 08:29:21 <abrkn> SomeoneWeird: i've looked at all of those, yes. it's a mess
110 2012-11-21 08:29:42 <SomeoneWeird> it is?
111 2012-11-21 08:29:48 <abrkn> have a look yourself
112 2012-11-21 08:29:56 <SomeoneWeird> i have
113 2012-11-21 08:30:06 <SomeoneWeird> i wouldn't exactly call it a mess, but eh
114 2012-11-21 08:30:41 <sipa> abrkn: the problem with brainwallets is that humans are notoriously bad at estimating how random a passphrase is
115 2012-11-21 08:31:00 <sipa> abrkn: especially as the entire world can watch and try to brute force
116 2012-11-21 08:31:22 <t7> choose a number between 1 and 10... it was 7... if not it was 3
117 2012-11-21 08:32:10 <t7> i once got a free pint using that trick
118 2012-11-21 08:32:22 <SomeoneWeird> huh
119 2012-11-21 08:32:33 <sipa> abrkn: nothing wrong with deterministic wallets of course, but if all your randomness originates from a human, you're going to see a lot of cracked wallets
120 2012-11-21 08:34:42 <abrkn> SomeoneWeird: the idea behind bitcoin server etc is very nice, but it's written by a person who cannot possibly understand node
121 2012-11-21 08:34:54 <abrkn> SomeoneWeird: to keep something maintainable, you need to split it into many small modules
122 2012-11-21 08:35:05 <SomeoneWeird> agreed, ofc
123 2012-11-21 08:35:33 <abrkn> SomeoneWeird: even in the node.js core they admit they it has become very hard to maintain things as easy as fs and http =)
124 2012-11-21 08:35:38 <abrkn> and thats a big ass team
125 2012-11-21 08:39:19 <SomeoneWeird> it is
126 2012-11-21 08:39:22 <SomeoneWeird> and a very smart one too :)
127 2012-11-21 08:39:39 <t7> heheh
128 2012-11-21 11:29:31 <jouke> Hmmm, I am not getting any respons out of my bitcoin client, but I see it is still using a little cpu
129 2012-11-21 11:29:43 <jouke> and I see the debug.log is registering my requests
130 2012-11-21 11:38:36 <jouke> well, had to kill -9 it :(
131 2012-11-21 11:41:02 <xIsalty> Question, Does the reward amount of the block have any effect on the size of the block ?
132 2012-11-21 11:48:23 <epscy> xIsalty: no
133 2012-11-21 11:48:31 <xIsalty> ok
134 2012-11-21 11:48:36 <epscy> it can however include any tx fess
135 2012-11-21 11:48:40 <epscy> er fees
136 2012-11-21 11:49:10 <epscy> so in total you may get more for mining a block than just the reward
137 2012-11-21 11:52:44 <jouke> Ok, moving makes the client freeze...
138 2012-11-21 11:53:00 <jouke> it worked before :(
139 2012-11-21 11:53:34 <jouke> Damn this sucks :(
140 2012-11-21 11:54:57 <jouke> any one here to help me make a bug ticket?
141 2012-11-21 11:56:56 <jouke> I see in the debug log, it's still making connections, but I can't get any reponse :(
142 2012-11-21 11:56:58 <rdponticelli> jouke: There has been some fix recently for that bug
143 2012-11-21 11:57:07 <jouke> I am running 7.1
144 2012-11-21 11:57:41 <rdponticelli> But I think it isn't released still...
145 2012-11-21 11:57:57 <rdponticelli> s/still/yet/
146 2012-11-21 11:59:02 <jouke> https://github.com/bitcoin/bitcoin/pull/2009
147 2012-11-21 12:00:51 <rdponticelli> jouke: Yes, looks like that's the one
148 2012-11-21 12:01:02 <jouke> Damn, we just made a huge investment to our website, relying on the move function :(
149 2012-11-21 12:03:43 <rdponticelli> They were waiting for some other fix to release 7.2...
150 2012-11-21 12:07:59 <jouke> If I patch the 7.1 source with this: https://github.com/bitcoin/bitcoin/issues/2021#issuecomment-10472113
151 2012-11-21 12:08:07 <jouke> would it be enough?
152 2012-11-21 12:09:33 <jouke> meh, I would really like 7.2 :(
153 2012-11-21 12:09:33 <Luke-Jr> jouke: yes
154 2012-11-21 12:09:56 <jouke> Luke-Jr: thanks, I guess I'll try that first.
155 2012-11-21 12:10:18 <Luke-Jr> jouke: as noted in that issue, we're just waiting on #2024 to get reviewed
156 2012-11-21 12:10:33 <Luke-Jr> you can help bring 0.7.2 sooner by testing that
157 2012-11-21 12:11:24 <jouke> We don't really have an other choice :x
158 2012-11-21 12:12:48 <Luke-Jr> jouke: ?
159 2012-11-21 12:13:55 <jouke> I am not going to try it to really test it, but to make our website work to its full potential
160 2012-11-21 12:15:31 <Luke-Jr> jouke: if you really don't want to test 0.7.2 before it's ready, perhaps 0.6.4rc4 would make sense for you
161 2012-11-21 12:38:10 <xenland> Is it possible to use a Bitcoin address to decrypt something if it was originally encrypted with the bitcoin address private key? or is that not feasable with out alteration?
162 2012-11-21 12:38:11 <xenland> Is it possible to use a Bitcoin address to decrypt something if it was originally encrypted with the bitcoin address private key? or is that not feasable with out alteration?
163 2012-11-21 12:40:09 <kjj_> xenland: not really, no
164 2012-11-21 12:41:02 <xenland> kjj_: Not its not feasible? or no, I'd have to do something to the bitcoin address first?
165 2012-11-21 12:41:27 <edcba> i don't understand the question
166 2012-11-21 12:41:30 <kjj_> private keys are just 256 bit strings, and could be used as encryption keys, but the pubkeys aren't useful for asymetric crypto schemes, only signatures
167 2012-11-21 12:42:19 <kjj_> we use ECDSA where the DSA part stands for "Digital Signature Algorithm"
168 2012-11-21 12:43:57 <kjj_> even worse, the address isn't the pubkey, it is a hash of the pubkey. so even if there was an asymetric system that could use our keys, the addresses aren't enough
169 2012-11-21 12:51:35 <jouke> Ok, patched version seems to work fine for now.
170 2012-11-21 12:54:53 <Luke-Jr> xenland: ECDSA doesn't support encryption
171 2012-11-21 12:55:15 <Luke-Jr> jouke: did you include #2024 in your patch by any chance?
172 2012-11-21 12:55:49 <xenland> kjj_ thanks for answer my question mate
173 2012-11-21 12:57:48 <jouke> Luke-Jr: no. I don't use bitcoin-qt and I don't use windows
174 2012-11-21 13:02:20 <Luke-Jr> jouke: still need to test that it doesn't hurt non-Windows ;)
175 2012-11-21 13:02:41 <jouke> ok, good point.
176 2012-11-21 13:06:21 <abrkn> anyone have working code for mtgox redeem ticket api? v0 seems broken, v1 not implemented
177 2012-11-21 13:06:30 <abrkn> *voucher
178 2012-11-21 13:06:54 <Luke-Jr> abrkn: #mtgox
179 2012-11-21 13:17:16 <abrkn> hmm, how long does it usually to get something confirmed on tn3
180 2012-11-21 13:17:27 <abrkn> mine says unconfirmed after like 5 hours
181 2012-11-21 13:17:42 <sipa> if nobody mines: forever
182 2012-11-21 13:18:30 <abrkn> i'd do my testing on real net if it wasn't so expensive ;)
183 2012-11-21 13:20:02 <abrkn> jouke: didnt see what you wrote before. i had that move bug too, had to revert to previous version
184 2012-11-21 13:20:18 <abrkn> jouke: the whole client would just freeze up forever
185 2012-11-21 13:20:20 <xenland> abrkn: I haven't tried this myself but this might work: try disabling test net from downloading blocks, delete the block chain, and mine on testnet your self with the lowest difficulty :)
186 2012-11-21 13:21:05 <abrkn> xenland: mining kills my laptop. i guess i'll have to go real net
187 2012-11-21 13:21:52 <xenland> that works too
188 2012-11-21 13:54:17 <abrkn> any way to make blockchain.info bitcoin compat rpc to support labels? (getAccountaddress fails with label not known for new labels)
189 2012-11-21 15:19:35 <TD> good evening
190 2012-11-21 15:26:10 <helo> i'll stop pasting reddit links if anyone wants me to, but since the discussion is dev related... http://www.reddit.com/r/Bitcoin/comments/13jj0d/in_favor_of_not_increasing_the_block_size/c74lzkq
191 2012-11-21 15:27:03 <helo> and poorly reasoned comments are getting a lot of upvotes :/
192 2012-11-21 15:30:43 <TD> ACTION looks
193 2012-11-21 15:32:41 <TD> those kinds of discussions are really best had on the forums indeed
194 2012-11-21 15:32:44 <TD> or directly with developers
195 2012-11-21 15:32:51 <TD> though i see jeff is taking part
196 2012-11-21 15:35:25 <TD> these discussions are all old and long since thrashed out though
197 2012-11-21 15:35:45 <TD> more and more i think we need to shift the FAQ off the wiki and onto the main website, along with discussions of common concerns like these
198 2012-11-21 15:35:52 <TD> otherwise the same discussions just come up again and again
199 2012-11-21 15:40:39 <TD> it'd also be a good forcing function for reaching consensus
200 2012-11-21 15:41:28 <weex> people are going to discuss things no matter what, over time more people will remember and link back to the old forum discussion or the FAQ or as you say bitcoin.org
201 2012-11-21 15:41:58 <weex> Bitcoin provides a lot of ground to cover and I'm always amazed how many times certain things have been explained in text form
202 2012-11-21 15:41:59 <weex> Bitcoin provides a lot of ground to cover and I'm always amazed how many times certain things have been explained in text form
203 2012-11-21 15:42:42 <weex> I've encouraged some to write in the wiki instead and link to that but at some point people just enjoy writing
204 2012-11-21 15:52:44 <helo> it is a lot more interesting to think of the distant future where the block size is still at 1MB
205 2012-11-21 15:52:48 <helo> for me, at least
206 2012-11-21 15:54:37 <helo> e.g. trivial to run a full node (so full nodes potentially everywhere), with bitcoin moving "upmarket" to high value transactions, very high fees and hashrate, etc
207 2012-11-21 16:01:29 <kjj_> sweet. my offline multisig batch generator appears to be fully functional
208 2012-11-21 16:47:08 <ciscoftw> what determines where my transaction(s) go when i try to send btc? when i broadcast my transactoin, seems like it'd be completely random who trys to include that trans into the block hash there're solving for.
209 2012-11-21 16:47:50 <ciscoftw> ...sometime i can send .05 (any small amont) without a fee, and other times it requires a transaction fee be included? why is this?
210 2012-11-21 16:49:13 <kjj_> decentralized
211 2012-11-21 16:49:39 <sipa> it depends on the transaction created, and in particular the age and size of the input coins used
212 2012-11-21 16:49:45 <kjj_> coin age and priority is still a big factor, but there is no global policy for such things. everyone makes their own decision
213 2012-11-21 16:59:20 <ciscoftw> so its the bitcoin client im using that makes the determination (based on coin age, and others?) if a fee is required or not? doesnt seem right, i know miners may choose to omit my tranaction if they choose...
214 2012-11-21 16:59:40 <kjj_> it makes the best guess it can
215 2012-11-21 16:59:51 <sipa> ciscoftw: it tries to guess whether miners will accept it
216 2012-11-21 17:00:01 <sipa> with/without fee
217 2012-11-21 17:00:03 <ciscoftw> based on coin age alone?
218 2012-11-21 17:00:20 <Cusipzzz> and size
219 2012-11-21 17:00:21 <sipa> no, also size of the transaction
220 2012-11-21 17:00:23 <sipa> and amount
221 2012-11-21 17:00:30 <kjj_> right now, the "fee" is 99% spam prevention and 1% fee. the transition to actually using the fee system mostly for fees will take a while, and it hasn't been invented yet
222 2012-11-21 17:00:31 <ciscoftw> size makes perfect sense, not age though
223 2012-11-21 17:00:49 <sipa> sure it does - age is necessary to prevent people from sending the same small coin over and over again
224 2012-11-21 17:00:51 <Cusipzzz> age check reduces spam and DOS attack
225 2012-11-21 17:01:05 <ciscoftw> ummm, that does make sense
226 2012-11-21 17:02:01 <ciscoftw> is it possible to send froma specific address via gui?
227 2012-11-21 17:02:32 <sipa> no, you can do so using the raw transaction API though
228 2012-11-21 17:02:33 <kjj_> no. also not possible from RPC since coins don't come from addresses
229 2012-11-21 17:02:39 <ciscoftw> how does the client choose which addresses the coins are sent from?
230 2012-11-21 17:03:02 <sipa> ciscoftw: it's a heuristic that tries to minimize the number of inputs used, and considers older one first
231 2012-11-21 17:03:09 <sipa> but it's far from perfect
232 2012-11-21 17:06:13 <ciscoftw> if coin age is determined by an address that holds the btc, what would stop someone from sending coins that belonged to a new address to the old address?
233 2012-11-21 17:06:34 <kjj_> there are no addresses
234 2012-11-21 17:06:59 <kjj_> coin age is determined by the age of the transaction output that is being redeemed
235 2012-11-21 17:07:20 <ciscoftw> thought the coins themseleves were nothing but placeholders
236 2012-11-21 17:08:28 <kjj_> erm, coin is polyvalent. in one sense it means the abstract unit of account. but the way I'm using it now, I mean "the output of a previous transaction"
237 2012-11-21 17:09:54 <kjj_> your wallet has a list of unspent transaction outputs (coins) of various values (denominated in coins, see the confusion?) when you spend, you take one or more of those coins, and forge them into one or more new coins with new values
238 2012-11-21 17:12:08 <kjj_> we seriously need a bootcamp tutorial for this. I hope I have enough time over the weekend to write one
239 2012-11-21 17:12:55 <ciscoftw> dude, i would read the fuck outta that tut kjj
240 2012-11-21 17:13:39 <kjj_> sitting down and actually making a few transactions using the raw API clears up so much confusion
241 2012-11-21 17:14:05 <ciscoftw> never done that
242 2012-11-21 17:14:10 <ciscoftw> link to get me started?
243 2012-11-21 17:14:14 <kjj_> the default client hides a LOT of details from the user, which is good for most users
244 2012-11-21 17:14:20 <kjj_> https://en.bitcoin.it/wiki/Raw_Transactions
245 2012-11-21 17:14:26 <kjj_> https://people.xiph.org/~greg/escrowexample.txt
246 2012-11-21 17:14:31 <kjj_> https://people.xiph.org/~greg/signdemo.txt
247 2012-11-21 17:14:54 <ciscoftw> many thanx kjj_
248 2012-11-21 17:15:05 <kjj_> that first link is docs on the API itself. the others are example uses. the signdemo.txt is probably the most immediately useful
249 2012-11-21 17:15:45 <kjj_> heh. thank Gavin and gmaxwell. they wrote that stuff
250 2012-11-21 17:17:15 <Cusipzzz> kjj_: very cool. thought it was for multisig or coin selection, didn't think of using it to send "offline coins"
251 2012-11-21 17:17:18 <kjj_> but just using listunspent, getrawtransaction and decoderawtransaction on your own wallet will reveal a lot
252 2012-11-21 17:17:44 <gavinandresen> there's also a raw transactions walkthrough at https://gist.github.com/3966071
253 2012-11-21 17:18:14 <kjj_> yeah, I was looking for that link to add to the pile.
254 2012-11-21 17:18:26 <gavinandresen> That one requires git HEAD to work
255 2012-11-21 17:18:57 <kjj_> I'm going to add those links to the wiki page
256 2012-11-21 17:18:58 <kjj_> I'm going to add those links to the wiki page
257 2012-11-21 17:19:16 <ciscoftw> anybody using the wireshark dissector here?
258 2012-11-21 17:22:45 <kjj_> it probably would have been a good idea to push out 0.7.2 including the multisig/raw fixes, rather than putting it off for 0.8/ultraprune
259 2012-11-21 17:24:48 <Cusipzzz> on a raw txn if there is change it all goes to fees unless specified?
260 2012-11-21 17:25:19 <kjj_> gavinandresen: how would you feel about letting the user import a list of addresses to be used for change? the use case is offline/multisig
261 2012-11-21 17:25:55 <kjj_> Cusipzzz: you have complete control over the inputs used and the outputs specified. if the inputs add up to more than the outputs, whatever is left is the change
262 2012-11-21 17:26:15 <kjj_> be careful, that could be a lot if you don't pay attention
263 2012-11-21 17:26:20 <gavinandresen> kjj_: I think that should wait on a deterministic wallet redesign. Change address should be a branch of a hierarchical determinisitc wallet, I think
264 2012-11-21 17:26:23 <Cusipzzz> right, but if inputs > output, it goes to fees
265 2012-11-21 17:27:58 <kjj_> gavinandresen: as part of my offline cold wallet redesign, I made 50 new 2-of-3 addresses. right now, if I want to use them, I have to do raw transactions all the way. not a big deal, but it would be nice if my change could automatically be redirected to safe keys
266 2012-11-21 17:28:01 <gavinandresen> Cusipzzz: correct. I'd suggest playing on testnet with play money if you're writing raw transactions code or experimenting by hand
267 2012-11-21 17:29:33 <kjj_> heh. real men do their tests live and with real money. real men are stupid and poor.
268 2012-11-21 17:30:05 <Cusipzzz> gavinandresen: thanks. testing on new wallet with small amounts :) - i've lost plenty testing old .3 stuff back in the day
269 2012-11-21 17:32:42 <jgarzik> ACTION spies a gavinandresen
270 2012-11-21 17:33:11 <jgarzik> gavinandresen: possible P2SH issue/question, in VerifyScript()
271 2012-11-21 17:33:55 <gavinandresen> jgarzik: yes?
272 2012-11-21 17:34:22 <jgarzik> gavinandresen: VerifyScript() directly accesses stackCopy.back(). stackCopy is obtained following the _first_ EvalScript(), yet the stack.empty() check follows the _second_ EvalScript(). Are you 100% certain that a stackCopy.empty() is not also needed, prior to accessing stackCopy.back() ?
273 2012-11-21 17:37:17 <gavinandresen> You mean before the third P2SH EvalScript?
274 2012-11-21 17:37:27 <jgarzik> gavinandresen: correct
275 2012-11-21 17:37:58 <gavinandresen> thinking... thinking....
276 2012-11-21 17:38:11 <gavinandresen> (interrupted, one sec)
277 2012-11-21 17:38:57 <jgarzik> gavinandresen: no rush. Gotta run out and get lunch + kid medical supplies. Then clean vomit. Then return to your reply ;p
278 2012-11-21 17:41:44 <gavinandresen> jgarzik: a stackCopy.empty() check before the third EvalScript would be wrong.
279 2012-11-21 17:42:19 <jgarzik> gavinandresen: !empty() to be specific
280 2012-11-21 17:42:30 <jgarzik> gavinandresen: empty() condition would be wrong, yes.
281 2012-11-21 17:43:14 <jgarzik> gavinandresen: so the question is, should we add a "if stackCopy.empty() return false;" prior to accessing stackCopy.back() ?
282 2012-11-21 17:43:19 <gavinandresen> Here's how I reason about it: imagine calling VerifyScript with a scriptSig of an empty array and a scriptPubKey of just OP_1
283 2012-11-21 17:43:20 <gavinandresen> Here's how I reason about it: imagine calling VerifyScript with a scriptSig of an empty array and a scriptPubKey of just OP_1
284 2012-11-21 17:43:44 <jgarzik> the empty() condition is clearly wrong. the question is... is it _possible_?
285 2012-11-21 17:43:58 <jgarzik> if it is possible, back() will cause crash
286 2012-11-21 17:44:13 <jgarzik> a !empty() check would prevent such a crash
287 2012-11-21 17:44:14 <jgarzik> a !empty() check would prevent such a crash
288 2012-11-21 17:45:34 <gavinandresen> ah, I see... lemme think on that a bit
289 2012-11-21 17:47:41 <gavinandresen> wait, which back() will crash? there is an if (stackCopy.empty()) check on line 1667
290 2012-11-21 17:48:26 <jgarzik> const valtype& pubKeySerialized = stackCopy.back();
291 2012-11-21 17:48:38 <jgarzik> gavinandresen: that line is prior to the stackCopy.empty() check
292 2012-11-21 17:48:45 <jgarzik> and prior to third EvalScript()
293 2012-11-21 17:48:46 <jgarzik> and prior to third EvalScript()
294 2012-11-21 17:49:05 <gavinandresen> oh, THAT one. If it is a P2SH script then the scriptPubKey MUST be HASH160 <blah> EQUAL
295 2012-11-21 17:49:26 <gavinandresen> And the only way that can be true is if scriptSig is not empty
296 2012-11-21 17:49:51 <gavinandresen> (HASH160 will fail if there is no item on the stack to hash)
297 2012-11-21 17:50:18 <gavinandresen> ... so no, no check is needed. A comment there saying why would be good, mea culpa.
298 2012-11-21 17:50:24 <jgarzik> gavinandresen: the specific condition is stack.empty() MUST be false, following first EvalScript()
299 2012-11-21 17:50:26 <jgarzik> gavinandresen: the specific condition is stack.empty() MUST be false, following first EvalScript()
300 2012-11-21 17:50:53 <jgarzik> gavinandresen: otherwise stackCopy.back() will fail
301 2012-11-21 17:51:01 <jgarzik> gavinandresen: if you guarantee that is the case, all good
302 2012-11-21 17:51:07 <gavinandresen> Right, if stack.empty() is true and it is a p2sh then the second EvalScript will return false.
303 2012-11-21 17:51:10 <sipa> a comment or an assert seem fine
304 2012-11-21 17:51:15 <jgarzik> ok
305 2012-11-21 17:51:16 <jgarzik> ok
306 2012-11-21 17:52:10 <gavinandresen> assert and comment : good idea
307 2012-11-21 17:55:52 <sipa> jgarzik: my node seems to run fine with your send/recv buffer change pulls
308 2012-11-21 17:56:59 <sipa> still trying to wrap my head around what the optimal value for data queued for sending should be before stopping receives, and whether whatever your OS provides is a good value for that
309 2012-11-21 17:58:17 <sipa> gavinandresen: thanks for continuing with the payment protocol stuff by the way, i'll have a look at the draft soon, but i've been a bit busy lately
310 2012-11-21 17:58:57 <gavinandresen> sipa: thanks, I was worried your lack of comments might have been because you were annoyed that I took your spec and started running with it
311 2012-11-21 17:59:47 <sipa> gavinandresen: no, not at all, it was written 1.5 years ago and i'd do things differently as well anyway
312 2012-11-21 17:59:57 <BlueMatt> sipa/gavinandresen: link to discussion of protocol?
313 2012-11-21 18:00:05 <sipa> protobufs seems like a good choice if you need consistent hashes
314 2012-11-21 18:00:19 <gavinandresen> BlueMatt: IT IS TOP SECRET! NEED TO KNOW BASIS ONLY!
315 2012-11-21 18:00:27 <BlueMatt> ok then...
316 2012-11-21 18:00:36 <Cusipzzz> zomg..scandal..to the forums :)
317 2012-11-21 18:00:41 <gavinandresen> BlueMatt: kidding. Public gist is at: https://gist.github.com/4120476 (only half-baked, though)
318 2012-11-21 18:00:42 <BlueMatt> lol
319 2012-11-21 18:01:37 <Cusipzzz> speaking of forums, i have contributed a few coins to devs who have btc addresses listed there, is there a consolidated list of dev tipping addresses?
320 2012-11-21 18:02:01 <BlueMatt> bitcoin foundation, probably
321 2012-11-21 18:02:07 <BlueMatt> (ie donate to btc foundation, not devs)
322 2012-11-21 18:02:23 <Cusipzzz> nah, not a fan of the foundation.
323 2012-11-21 18:02:26 <gavinandresen> Speaking of coins, I've got the core dev team grant from the foundation
324 2012-11-21 18:02:32 <BlueMatt> nice!
325 2012-11-21 18:02:41 <Cusipzzz> i prefer to give directly, but if some of you don't want it, ok
326 2012-11-21 18:03:12 <sipa> gavinandresen: one rasberry pi on a 64k ISDN line?
327 2012-11-21 18:03:26 <gavinandresen> sipa: no, we can afford at least two pi's
328 2012-11-21 18:04:04 <helo> are foundation membership stats published?
329 2012-11-21 18:04:18 <sipa> wow, that's at least 6.2831!
330 2012-11-21 18:05:57 <sipa> by the way: how about 0.7.2?
331 2012-11-21 18:06:09 <sipa> seems there are people actually waiting for it
332 2012-11-21 18:06:26 <BlueMatt> gavinandresen: thanks, Ill read through it sometime later over the holidays
333 2012-11-21 18:06:27 <Joric> i do! for what?
334 2012-11-21 18:07:00 <sipa> you do what for what?
335 2012-11-21 18:07:08 <Joric> <sipa> seems there are people actually waiting for it
336 2012-11-21 18:07:13 <gavinandresen> helo : I think Peter might blog about number of members, etc soon
337 2012-11-21 18:08:01 <gavinandresen> sipa: I'm about to get innundated with relatives for Thanksgiving, so I won't have time to figure out what's up with 0.7.2 until at least Monday
338 2012-11-21 18:08:25 <sipa> i'll try to go over luke's diff with 0.7.1
339 2012-11-21 18:08:54 <gavinandresen> And RE: the grant: we've got 470 BTC to spend. BlueMatt : first thing I want to do after purchasing a server is move jenkins....
340 2012-11-21 18:11:49 <Joric> theres something really wrong with the https://bitcoinfoundation.org layout the contact link is in the second row even on 1920x1080
341 2012-11-21 18:14:04 <kjj_> oh dear god, protocol buffers?
342 2012-11-21 18:14:04 <sipa> bah, hope i can move to a real apartment soon... in my temporary flat the only internet is wireless, and it sucks.... sometimes it's actually completely unavailable for hours or even days...
343 2012-11-21 18:14:26 <gavinandresen> kjj_: did you read the "Why not JSON?" section of the document yet?
344 2012-11-21 18:14:43 <kjj_> yeah, reading it now
345 2012-11-21 18:15:33 <kjj_> PB always seemed to me to be an attempt to replace all of the mistakes of ASN.1, JSON, XML, etc with entirely new and different mistakes.
346 2012-11-21 18:16:50 <gavinandresen> kjj_: The obvious candidates are PB or the bitcoin wire protocol serialization format. But expecting web servers to produce bitcoin wire protocol format Invoices seems like a worse idea
347 2012-11-21 18:17:04 <jgarzik> indeed
348 2012-11-21 18:18:48 <jgarzik> sipa: ACK. My main thesis is that leaving read always-on has been known to be bad behavior for application programs. Obviously that is somewhat orthogonal to OS buffer size. As mentioned, I can easily add "if vSend.size() > X { stop RX }" logic, on top of current patch.
349 2012-11-21 19:08:58 <gavinandresen> jgarzik: https://github.com/bitcoin/bitcoin/pull/2031 assert and comment for script.cpp
350 2012-11-21 19:08:58 <jgarzik> sipa: Thinking about various write-queue draining behaviors. If you are draining slowly, you don't want to queue more work (by reading more). If you are draining rapidly, the logic won't kick in.
351 2012-11-21 19:08:58 <kjj_> is multiple encodings a bad thing when signing? I know that it can be when the hash is pre-image-able
352 2012-11-21 19:37:07 <kjj_> sweet. my Wasp code reader showed up today, and it can read everything on my paper key printouts, even the full WIF encoded as code128B
353 2012-11-21 20:15:33 <jgarzik> hum
354 2012-11-21 20:15:48 <jgarzik> it is disappointing that the tx_valid.json tests do not include nValue in their inputs
355 2012-11-21 20:18:29 <gavinandresen> jgarzik: they could be extended, couldn't they? e.g. allow 3- or 4-valued arrays as inputs
356 2012-11-21 20:19:25 <jgarzik> gavinandresen: yep
357 2012-11-21 20:19:56 <jgarzik> for now, picocoin will follow bitcoin's example of testing VerifyScript() rather than the more exhaustive VerifySignature()
358 2012-11-21 20:21:38 <BlueMatt> jgarzik: eh...iirc doesnt tx_valid do VerifySignature?
359 2012-11-21 20:21:53 <jgarzik> BlueMatt: no
360 2012-11-21 20:22:13 <BlueMatt> oh...probably my fault, should be doing that iir the VerifyScript/VerifySignature difference correctly
361 2012-11-21 20:22:43 <BlueMatt> oh, nevermind Im misremembering that...not sure what the difference is then
362 2012-11-21 20:23:54 <BlueMatt> ah, well it doesnt matter much, does it?
363 2012-11-21 20:40:26 <midnightmagic> dnssec, trying to replace one CA for another since 1997. :(
364 2012-11-21 20:42:29 <kjj_> yeah. it turns out that PKI is actually hard to do. who could have known?
365 2012-11-21 20:42:44 <midnightmagic> i was thinking more about trust metrics.
366 2012-11-21 20:46:21 <jgarzik> hrm
367 2012-11-21 20:46:33 <jgarzik> ECDSA_verify does not like the first signature in tx_valid.json
368 2012-11-21 20:46:38 <kjj_> heh. the only trust model that is actually worse than CAs. :)
369 2012-11-21 20:46:59 <jgarzik> ["The following is 23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63"],
370 2012-11-21 20:47:06 <jgarzik> but OpenSSL does not accept it here ;p
371 2012-11-21 20:47:24 <kjj_> do you have a newer version of OpenSSL maybe?
372 2012-11-21 20:47:41 <kjj_> every now and then, they do slip up and let bugfixes sneak in
373 2012-11-21 20:47:55 <jgarzik> heh
374 2012-11-21 20:48:09 <jgarzik> well, one would think bitcoin itself would break, if so
375 2012-11-21 20:48:19 <jgarzik> but bitcoin works and picocoin's test fails, on the same system with same lib
376 2012-11-21 20:49:09 <kjj_> I haven't looked at those parts of the bitcoin code much, but my understanding was that the crypto stuff in bitcoin was mostly just a thin veneer over openssl library calls
377 2012-11-21 20:49:59 <kjj_> are you sure you are preparing and calling in the same way?
378 2012-11-21 20:50:49 <jgarzik> AFAICS yes
379 2012-11-21 20:50:58 <jgarzik> and it passes all the script*.json tests, valid & invalid
380 2012-11-21 20:51:59 <jgarzik> ["The following is f7fdd091fa6d8f5e7a8c2458f5c38faffff2d3f1406b6e4fe2c99dcc0d2d1cbb"],
381 2012-11-21 20:52:05 <jgarzik> one wonders... what was the workaround?
382 2012-11-21 20:52:19 <BlueMatt> I dont remember anymore (and didnt by the time I had written that...)
383 2012-11-21 20:52:22 <BlueMatt> sorry :(
384 2012-11-21 20:52:32 <jgarzik> gavinandresen, sipa: any recall of what was the workaround?
385 2012-11-21 20:52:42 <BlueMatt> jgarzik: it was in my bitcoinj branch
386 2012-11-21 20:53:08 <BlueMatt> oh, yes, I do
387 2012-11-21 20:53:43 <BlueMatt> I hadnt actually bothered to look at the bouncycastle lib and had just tried to modify the biginteger sign manually, still not sure why it didnt work but Im assuming it was some dumb mistake
388 2012-11-21 21:11:02 <jgarzik> BlueMatt: hmmm that doesn't clear things up
389 2012-11-21 21:11:12 <jgarzik> BlueMatt: what url or commit?
390 2012-11-21 21:11:17 <BlueMatt> jgarzik: nope, hence the vagueness in the file there...
391 2012-11-21 21:11:43 <BlueMatt> dont know that I ever pushed it anywhere (it was, after all, broken...)
392 2012-11-21 21:12:15 <jgarzik> Well clearly the workaround exists in bitcoin, otherwise the tests would not pass. Unless I'm missing something.
393 2012-11-21 21:12:26 <BlueMatt> no, its an openssl thing
394 2012-11-21 21:12:32 <BlueMatt> (and bouncycastle)
395 2012-11-21 21:18:21 <jgarzik> BlueMatt: As mentioned above, both bitcoind and picocoin are using the same OpenSSL lib. test_bitcoin works just fine.
396 2012-11-21 21:26:00 <BlueMatt> jgarzik: and that test is failing for you too?
397 2012-11-21 21:26:47 <BlueMatt> jgarzik: that one will only pass if the first one (the one that tests for negative values in der) passes too, btw, so you may just be seeing the issue tested in that first one
398 2012-11-21 21:27:37 <jgarzik> BlueMatt: picocoin imports bitcoin tests
399 2012-11-21 21:27:56 <jgarzik> BlueMatt: test_bitcoin, build inside the bitcoin/bitcoin.git source base as usual, works
400 2012-11-21 21:28:02 <jgarzik> BlueMatt: picocoin's tests, using same data, fails
401 2012-11-21 23:26:03 <sipa> BlueMatt: #1980 passed; you can switch back
402 2012-11-21 23:28:27 <sipa> jgarzik: well clearly if your test fails, and the one in bitcoin succeeds, the code is not identical?
403 2012-11-21 23:39:07 <BlueMatt> sipa: thanks
404 2012-11-21 23:55:00 <jgarzik> sipa: yes
405 2012-11-21 23:55:10 <jgarzik> sipa: and in trying to understand that failure, I need to understand the test
406 2012-11-21 23:55:15 <jgarzik> sipa: the test mentions a workaround
407 2012-11-21 23:55:36 <jgarzik> Still not clear what, specifically, is that workaround
408 2012-11-21 23:55:50 <jgarzik> or where
409 2012-11-21 23:56:09 <jgarzik> the rest is my problem