1 2014-02-04 00:03:23 <devrandom> tlrobinson: merged
2 2014-02-04 00:03:42 <devrandom> tlrobinson: that's an interesting idea... however, I want to check if there are security implications
3 2014-02-04 00:03:54 <devrandom> i.e. where does vagrant get images?
4 2014-02-04 00:04:43 <devrandom> http://cloud-images.ubuntu.com/vagrant
5 2014-02-04 00:05:22 <devrandom> should at least change that to https, and would be better if it was possible to check via PGP
6 2014-02-04 00:09:09 <devrandom> tlrobinson: I created a couple of issues to keep track of these questions https://github.com/devrandom/gitian-builder/issues?state=open
7 2014-02-04 00:51:32 <petertodd> gmaxwell: looks like that forked webbtc.com again...
8 2014-02-04 00:54:53 <gmaxwell> ::sigh::
9 2014-02-04 00:55:00 <gmaxwell> is coinbase broken too then?
10 2014-02-04 00:55:54 <sipa> what forked it?
11 2014-02-04 00:56:23 <gmaxwell> yep...
12 2014-02-04 00:56:33 <gmaxwell> 14:00 < gmaxwell> petertodd: we need a bunch of tests that look like <badsig> OP_CHECKSIG OP_NOT
13 2014-02-04 00:56:37 <gmaxwell> 14:00 < petertodd> gmaxwell: oh, that's not in the chain?
14 2014-02-04 00:56:39 <gmaxwell> 14:00 < gmaxwell> I don't think we have any that look that that right now. (unless someone did some recently)
15 2014-02-04 00:56:41 <petertodd> gmaxwell: looks like it
16 2014-02-04 00:56:43 <gmaxwell> 14:01 < gmaxwell> in general we should take every positive test, make a failing version of it, and invert it.
17 2014-02-04 00:56:52 <gmaxwell> 14:09 < petertodd> gmaxwell: done, txid df95ff9ac165abe7adb0091b5f1020c25203fd0c16c95b4c7fa6a4475428ef1f spending c9d5ce246e3795531b2fc43f6d6d341dfbe34c8ae08f9dd3ac481213f72e30fb
18 2014-02-04 00:56:55 <petertodd> gmaxwell: block 284029 did them in
19 2014-02-04 00:57:09 <petertodd> and https://coinbase.com/network/blocks is showing orphaned blocks after that
20 2014-02-04 00:58:17 <petertodd> interestingly the list of orphans isn't complete; they're missing three blocks after that
21 2014-02-04 01:01:02 <petertodd> heh, and I'll bet you they're already manually forcing it to work... now 284029 shows as "main"
22 2014-02-04 01:02:35 <gmaxwell> It's really disappointing that it's so easy to break things. These are not especially tricky tests.
23 2014-02-04 01:03:52 <petertodd> they really aren't; that's the kinda thing you could get right just from reading the wiki
24 2014-02-04 01:04:11 <petertodd> a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d <- this is a much more subtle one
25 2014-02-04 01:06:11 <sipa> OP_CHECKSIG in an input script?
26 2014-02-04 01:06:23 <petertodd> sipa: heh, you looked that up on bc.i...
27 2014-02-04 01:07:03 <petertodd> sipa: (there's a bug on bc.i related to that tx)
28 2014-02-04 01:07:23 <sipa> i admit :'(
29 2014-02-04 01:08:42 <petertodd> besides, they're both p2sh inputs, how could CHECKSIG be the last pushdata in the scriptSig?
30 2014-02-04 01:19:50 <tlrobinson> devrandom: cool, yeah
31 2014-02-04 01:56:40 <petertodd> gmaxwell: and forked again by 284039
32 2014-02-04 01:57:59 <petertodd> gmaxwell: lol! https://github.com/lian/bitcoin-ruby/commit/19330edd83a4e5ef3b449f434b0c5256d2a2d2aa "fix success state return in Script#op_checkmultisig"
33 2014-02-04 01:59:26 <petertodd> gmaxwell: looks like 09bdfd8bd713658612594e2d6df5e7f80ba3898e3ae3c6b3aa8ef986204d1e1e did them in; they don't have the logic in ConvertToBool() at all
34 2014-02-04 02:00:06 <petertodd> gmaxwell: they certainely didn't handle the negative zero case properly
35 2014-02-04 02:01:08 <gmaxwell> lianj: Sorry for the fire drill.
36 2014-02-04 02:01:23 <andytoshi> bc.i shows 0.05 btc still on the OP_CHECKSIG OP_NOT address..
37 2014-02-04 02:01:29 <gmaxwell> lianj: though if you have that bug I suspect there are other ones like it.
38 2014-02-04 02:01:46 <petertodd> lianj: just run bitcoin core locally and if it gives you a tx, trust it's real
39 2014-02-04 02:01:54 <petertodd> lianj: same advice I give everyone...
40 2014-02-04 02:02:09 <petertodd> lianj: there's no need to have a EvalScript() implementation at all
41 2014-02-04 02:02:41 <petertodd> andytoshi: there's a few things I left around delibrately :)
42 2014-02-04 02:03:03 <andytoshi> petertodd: ok, cool, it's yours. i'll give it back if i can get it..
43 2014-02-04 02:03:05 <petertodd> andytoshi: heck, I threw in some unspendable edge cases in there too
44 2014-02-04 02:03:55 <flound1129> is there a reason bitcoind won't use more than 1 cpu?
45 2014-02-04 02:05:02 <petertodd> andytoshi: give it to eligus - I use relatively high fees for these games because they deserve it for the useful service they're providing
46 2014-02-04 02:05:36 <justanotheruser> Is there a reason soft-spending is disallowed?
47 2014-02-04 02:05:54 <andytoshi> petertodd: http://0bin.net/paste/h72f7wSVGv2XfKVL#2lOEVJIIdLTPqu+rptkMW+ycfcwaTLUEykXbJGi8ls0= sent to eligius. but my own local bitcoind rejected it so i'm unsure.
48 2014-02-04 02:06:01 <andytoshi> and ooops i forgot to put a fee on it
49 2014-02-04 02:06:58 <andytoshi> damn, they won't take a new one with a fee. bc.i rejects it outright with "Invalid signature" <.<
50 2014-02-04 02:08:03 <petertodd> andytoshi: ah, well, someone will get it eventually
51 2014-02-04 04:45:24 <coins> I need some help with compiling the windows wallet
52 2014-02-04 04:45:47 <coins> Currently getting this error: undefined reference to boost::program_options::detail:common_config_file_iterator::get()
53 2014-02-04 04:45:58 <coins> and some others along the lines of that
54 2014-02-04 04:46:13 <coins> my libs are linked correctly
55 2014-02-04 04:46:48 <coins> -l boost_program_options-mgw48-1_53
56 2014-02-04 04:52:07 <coins> please.
57 2014-02-04 04:53:26 <Luke-Jr> coins: you'll have to get in touch with Diapolo; nobody else uses Windows
58 2014-02-04 04:53:45 <coins> understandable, I can see exactly why
59 2014-02-04 04:58:42 <coins> how could I find this person
60 2014-02-04 07:01:26 <davec_> the help for getnettotals shows " \"timemillis\": t (numeric) Total cpu time\n" but obj.push_back(Pair("timemillis", static_cast<boost::int64_t>(GetTimeMillis())));
61 2014-02-04 07:01:42 <davec_> which is milliseconds since epoch unless I'm misreading that func
62 2014-02-04 08:20:53 <sipa> flound1129: it will, after the lastr checkpoint, where signature checking is enabled
63 2014-02-04 09:30:57 <jaekwon> can you spend a bitcoin transaction output immediately, or are you required to wait for X confirmations?
64 2014-02-04 09:31:43 <stonecoldpat> you have to wait for 1 confirmation i believe
65 2014-02-04 09:32:14 <stonecoldpat> (might be possible without any confirmation) - but it opens you up to a double spending attack
66 2014-02-04 09:32:19 <Luke-Jr> jaekwon: you don't need it to confirm (at all), unless it's generation, in which case there are 100 blocks before you can spend
67 2014-02-04 09:32:43 <stonecoldpat> Luke-Jr: 100 blocks? why is that? (out of interest)
68 2014-02-04 09:32:53 <Luke-Jr> jaekwon: for the reason stonecoldpat mentioned, it's preferable to wait until it's in a block, though - otherwise the UTXO id could change innocently
69 2014-02-04 09:33:04 <Luke-Jr> stonecoldpat: one of Satoshi's arbitrary numbers with no reason
70 2014-02-04 09:33:30 <Luke-Jr> stonecoldpat: the reason for a delay at all, is because a reorg would invalidate it entirely, not merely require reconfirmation
71 2014-02-04 09:35:17 <jaekwon> Luke-Jr, thanks for that. My situation is pretty complicated⦠The outputs that I spend would all be outputs controlled by me. It's a matter of processing customer withdrawalsâ¦
72 2014-02-04 09:35:38 <stonecoldpat> Luke-Jr: Ah ok, you mean a reorganisation of the outputs?
73 2014-02-04 09:35:45 <jaekwon> If I need to wait 1 confirmation, then that means I need a supply of transaction outputs in order to be able to process withdrawals quickly.
74 2014-02-04 09:35:45 <Luke-Jr> jaekwon: I can't imagine a use case for that.
75 2014-02-04 09:35:54 <Luke-Jr> jaekwon: you need that in any case.
76 2014-02-04 09:35:54 <sipa> davec_: hmm, please file a bug for that; for consitency it should be seconds
77 2014-02-04 09:36:32 <Luke-Jr> jaekwon: oh, I think I see: you want to chain the change into another one quickly
78 2014-02-04 09:36:44 <sipa> jaekwon: the protocol allows spending immediately; many clients enforce 1 confirmation
79 2014-02-04 09:36:50 <Luke-Jr> jaekwon: you should probably strongly consider batching payments N at a time in a single transaction
80 2014-02-04 09:37:15 <Luke-Jr> if you're planning to have a lot of traffic, anyhow
81 2014-02-04 09:37:25 <jaekwon> If I don't need any confirmations at all, then maybe I don't need a supply of many small spendable outputs⦠I could just have one large output, and daisy chain withdrawals starting from that output, and hopefully all of those transactions go through in FIFO order. Does that make sense?
82 2014-02-04 09:37:46 <jaekwon> I'm already batching, yeah.
83 2014-02-04 09:38:02 <Luke-Jr> jaekwon: should work fine then
84 2014-02-04 09:38:15 <Luke-Jr> sipa: do any require 1 block for even your own sends?
85 2014-02-04 09:38:40 <jaekwon> OK, so it is possible to have two transactions, one dependent on the other, be broadcast & successfully confirmed in the same (next) block?
86 2014-02-04 09:38:46 <sipa> Luke-Jr: multibit did, but my information is likely outdated
87 2014-02-04 09:39:48 <jaekwon> thanks sipa & Luke-Jr
88 2014-02-04 09:44:06 <jaekwon> http://bitcoin.stackexchange.com/questions/1726/can-multiple-transactions-transferring-the-same-bitcoin-be-done-in-one-block
89 2014-02-04 09:51:19 <stonecoldpat> jaekwon: should work ok - i just wondering what if it the second transaction gets verified first (as invalid) then the first transaction gets accepted? don't know if that scenario could happen
90 2014-02-04 09:53:24 <sipa> stonecoldpat: it cannot be verified as it has missing inputs
91 2014-02-04 09:53:43 <sipa> so it is held in a waiting queue of orphan transactions
92 2014-02-04 09:54:06 <sipa> until the parent is received
93 2014-02-04 09:54:59 <Grouver> Hello, I just copied the entire blockchain (chainstate&blocks folder) from a 0.8.6 trusted node to my local pc. I am running the 0.9.0rc1. Now at the startup I get the error that bitcoin-qt didnt found a genisis block. Is this cause i cant use a 0.8.6 blockchain for a 0.9 client?
94 2014-02-04 09:56:30 <sipa> Grouver: it should work
95 2014-02-04 09:57:02 <sipa> Grouver: did you copy the datadir while bitcoin was running?
96 2014-02-04 09:57:16 <Grouver> At the startup I directly get the error: "Incorrect of geen genesis-blok gevonden. Verkeerde datamap voor het netwerk?"
97 2014-02-04 09:57:24 <Grouver> sipa, No.
98 2014-02-04 09:59:10 <sipa> sure you didn't cooy a testnet directory or something?
99 2014-02-04 09:59:38 <Grouver> sipa, Jouke copied it. Ill ask him to be sure.
100 2014-02-04 10:06:22 <Grouver> sipa, He is sure.
101 2014-02-04 10:06:22 <Grouver> sipa, Ther is a .lock file in the bitcoin dir now though. While iam not running bitcoin, at all.
102 2014-02-04 10:22:14 <sipa> gavinandresen, wumpus, jgarzik, gmaxwell: #3609 in 0.9.0rc2?
103 2014-02-04 10:27:29 <Grouver> sipa, I removed the /database/log files and /blocks/index folder now. But its still not working. Ill try to google some more.
104 2014-02-04 10:28:19 <sipa> if you have database/log files and a .lock file, it certainly was not a cleanly shutdown datadir you copied...
105 2014-02-04 10:29:48 <Grouver> I didnt copy the .lock file. This was already there. But I didnt force close the bitcoin client or anything.
106 2014-02-04 10:30:12 <Grouver> I also only copied the /blocks folder and /chainstate folder from the trusted node.
107 2014-02-04 10:30:40 <sipa> and are you sure no bitcoind was running on the node you copied it _to_ ?
108 2014-02-04 10:31:44 <Grouver> sipa, meh that must be it I think. Ill try again. Thanks.
109 2014-02-04 10:52:29 <freefox> guys, setting maxconnections=1 significantly increases the sync speed, is this known behavior?
110 2014-02-04 10:52:39 <sipa> yes
111 2014-02-04 10:52:53 <freefox> hey sipa
112 2014-02-04 10:52:55 <freefox> so this is a bug?
113 2014-02-04 10:53:05 <sipa> the whole synchronization mechanism is a bug
114 2014-02-04 10:53:10 <freefox> oh :)
115 2014-02-04 10:53:32 <sipa> it's being worked on, but wasn't completed for 0.9
116 2014-02-04 10:54:10 <freefox> good, hope it will be for the next version
117 2014-02-04 10:55:04 <freefox> you know if the "block headers only" download is being implemented?
118 2014-02-04 10:55:33 <sipa> i've been working on headers-first synchronization
119 2014-02-04 10:55:49 <freefox> how's it going?
120 2014-02-04 10:55:56 <sipa> i don't have enough time :)
121 2014-02-04 10:56:46 <freefox> I see
122 2014-02-04 10:57:09 <sipa> but headers-first isn't exactly headers-only (by that, i assume you refer to an SPV mode)
123 2014-02-04 10:57:19 <sipa> it just changes how we decide what to download
124 2014-02-04 10:57:57 <sipa> headers-only is quite different in that it only synchronizes the headers, so you need a wallet that can request transactions from peers (as the local node doesn't have transactions)
125 2014-02-04 10:58:03 <freefox> is it possible to download just the headers from existing clients, ie old versions?
126 2014-02-04 10:58:19 <sipa> sure, all SPV clients do
127 2014-02-04 10:58:28 <sipa> bitcoind just is not an SPV client
128 2014-02-04 11:00:10 <freefox> is there any reason why it shouldn't be?
129 2014-02-04 11:00:25 <sipa> it's just not implemented
130 2014-02-04 11:00:49 <sipa> ideally, you'd have a client that starts out as an SPV client, and gradually upgrades in the background to a full node if resources permit it
131 2014-02-04 11:07:21 <freefox> yeah that would be good
132 2014-02-04 11:09:16 <petertodd> sipa: interestingly it looks like colored coins actually may wind up testing that kind of code first
133 2014-02-04 11:12:01 <petertodd> The key thing is that CC basically does maintain a TXO set on a per-block basis, and at the same time it makes a lot of sense to have flexibility as to how you can update that set with newly known data, both block-by-block, partial blocks, and straight up "issuer said so" - the latter giving you a chance to do some fraud proof stuff.
134 2014-02-04 11:39:13 <ItsDom> If I'm looking at scriptPubKey, is it safe to assume that if I see 0x02 - 0x04, then the following bytes are a public key (based on https://en.bitcoin.it/wiki/Protocol_specification#Signatures)
135 2014-02-04 11:52:43 <stonecoldpat> would it be wrong to say - that a bitcoin address is a bit like a bank account?
136 2014-02-04 11:53:08 <stonecoldpat> (that should be a single use bank account)
137 2014-02-04 11:53:09 <ItsDom> yes. A bitcoin wallet is more like a bank account. A bitcoin address is more like a card to access that account.
138 2014-02-04 11:53:23 <ItsDom> no, you should use a different address for every transaction:)
139 2014-02-04 11:53:44 <stonecoldpat> yeah, thats what i mean by single use... but i forgot about the wallet, good catch
140 2014-02-04 11:54:06 <stonecoldpat> (becomes i own half a cent worth of bitcoins - a wallet is not useful to me normally!) x
141 2014-02-04 11:54:12 <ItsDom> indeed. But as long as you put "a bit like" then people will agree and disagree with varying amounts of likeness until the cows come home. it all depends on audience:)
142 2014-02-04 12:27:33 <sipa> ItsDom: no
143 2014-02-04 12:27:38 <sipa> ItsDom: it depends on how the bytes are used
144 2014-02-04 12:27:45 <michagogo> cloud|ItsDom: a scriptPubKey won't include a pubkey, usually
145 2014-02-04 12:29:00 <ItsDom> okay. So the only way to do it is actually parse the hex as script?
146 2014-02-04 12:29:29 <sipa> yes
147 2014-02-04 12:29:32 <ItsDom> michagogo|cloud: I know it's generally a hashed pubkey, I was referring mainly to identifying bits that are values or parameters (e.g. hashes or pub keys) rather than script functions
148 2014-02-04 12:29:50 <sipa> well, pattern match it against a known type of scripts
149 2014-02-04 12:30:36 <ItsDom> sipa: basically, I want to be able to look at the user friendly script of all the transactions, but my abe db only has hex of scriptPubKey
150 2014-02-04 12:30:43 <michagogo> cloud|ItsDom, script functions? You mean opcodes?
151 2014-02-04 12:30:50 <michagogo> cloud|And by "values or parameters", do you mean data pushes?
152 2014-02-04 12:31:19 <gribble> https://en.bitcoin.it/wiki/Script | Bitcoin uses a scripting system for transactions. Forth-like, Script ...
153 2014-02-04 12:31:19 <michagogo> cloud|Are you familiar with Bitcoin's Script? Definitely read ,,(bc,wiki script) if you haven't aleady
154 2014-02-04 12:33:21 <sipa> ItsDom: the only "user friendly" form is addresses
155 2014-02-04 12:33:46 <sipa> ItsDom: so you just pattern match against types of transactions that correspond to p2sh or pay-to-pubkeyhash
156 2014-02-04 12:33:55 <ItsDom> sipa: by user friendly, I mean OP_DUP instead of e.g. 0x61
157 2014-02-04 12:34:07 <sipa> oh
158 2014-02-04 12:34:13 <sipa> that's easy, just parse it :)
159 2014-02-04 12:34:45 <ItsDom> michagogo|cloud: yeah, I've read that page extensively. By value or parameters, I mean variable data in scriptPubKey as opposed to static commands like OP_OVER and such .
160 2014-02-04 12:35:07 <sipa> ItsDom: i don't understand why you need to know what a pubkey is, if you just want to disassemble
161 2014-02-04 12:35:36 <ItsDom> sipa: but I have to parse it though, right? I can't just take every byte and say if it equals a value in the wiki, thne convert it, it would have to be informed parsing (e.g. this caracter is OP_IF, so next characters are statements etc.)(
162 2014-02-04 12:35:55 <sipa> ItsDom: there is no such structure
163 2014-02-04 12:36:01 <sipa> a script is just a series op opcodes
164 2014-02-04 12:36:07 <sipa> some of which push data
165 2014-02-04 12:36:10 <ItsDom> sipa: I don't need to know specifically what is a pubKey, but if I want to do a lazy simple parse (e.g. each byte at a time) then that's only useful if I can identify bytes not to parse as OP codes
166 2014-02-04 12:36:37 <sipa> there is nothing but "lazy simple parse"
167 2014-02-04 12:36:51 <sipa> you just look at a byte, check in the table what it is, and continue to the next
168 2014-02-04 12:37:06 <ItsDom> sipa: lazy parse = look at each by independent of the last. clever parse = consider previous bytes.
169 2014-02-04 12:37:16 <sipa> you never need to consider previous bytes
170 2014-02-04 12:37:30 <ItsDom> sipa: if I do that, it wont work for commands like OP_IF because they're followed by data aren't they?
171 2014-02-04 12:37:40 <sipa> no they're not
172 2014-02-04 12:37:44 <ItsDom> oooh noo! it's stack based
173 2014-02-04 12:37:46 <sipa> OP_IF is just an opcode like every other
174 2014-02-04 12:38:35 <sipa> the only things you need to handle specially are data pushes
175 2014-02-04 12:38:36 <ItsDom> sipa: okay, but for example OP_PUSHDATA pushes the next few bytes to the stack
176 2014-02-04 12:38:50 <ItsDom> aaah, so the only pushes are the 3 pushes OP_PUISHDATA1,2 and 4?
177 2014-02-04 12:38:59 <sipa> no
178 2014-02-04 12:39:10 <sipa> those are effectly almost never used
179 2014-02-04 12:39:15 <sipa> there's also implicit data pushes
180 2014-02-04 12:39:31 <sipa> for example 0x20 means "push the following 32 bytes"
181 2014-02-04 12:39:48 <sipa> while OP_PUSHDATA takes an extra byte to specify the length of what is being pushed
182 2014-02-04 12:39:50 <ItsDom> seee, this is what I was getting at with parsing not being super simple (I mean, it's hardly advanced, I'm jsut slow:) )
183 2014-02-04 12:40:35 <michagogo> cloud|sipa: OP_PUSHDATA1 (and to a lesser extent -2) can be useful in e.g. P2SH though, right?
184 2014-02-04 12:40:36 <ItsDom> so the only way to actually convert the hex to opcodes would be to properly parse the hex to determine which bits are op_codes and parts are data for the op_code or to go onto the stack or similar?
185 2014-02-04 12:40:40 <sipa> michagogo|cloud: yup
186 2014-02-04 12:40:46 <sipa> ItsDom: yes
187 2014-02-04 12:40:54 <sipa> ItsDom: but it's not really complicated :)
188 2014-02-04 12:41:01 <michagogo> cloud|ItsDom: yeah, read a byte at a time, see what it is
189 2014-02-04 12:41:23 <michagogo> cloud|If it's any of the push opcodes, read the next bytes to see what you push
190 2014-02-04 12:41:30 <michagogo> cloud|And keep going until the end
191 2014-02-04 12:41:32 <ItsDom> sipa: ha, I know, I'm jsut being lazy. I want to be able to do it conveniently on the go through MySQL, without having to parse it all into another column (with 60million + rows it gets a bit slow)
192 2014-02-04 12:42:25 <ItsDom> Well, I really appreciate the help both of you. Sipa, if I had a penny everytime you've helped me out in the past, my copper jar would definitely be a good lot heavier than it is now:)
193 2014-02-04 12:44:15 <ItsDom> So just to confirm, any outputs from any of the op codes (as specified in the output column on the wiki) ends up on top of the stack?
194 2014-02-04 12:45:09 <michagogo> cloud|Yep
195 2014-02-04 12:45:55 <ItsDom> michagogo|cloud: okay, thanks for the help, again, really appreciated:)
196 2014-02-04 12:46:57 <ItsDom> 1 last question: is it possible for scriptpubkey to start with something other than an opcode? or would that be totally invalid?
197 2014-02-04 12:47:48 <sipa> well, every byte is an opcode pretty much
198 2014-02-04 12:47:57 <sipa> some are not assigned, but those are just invalid
199 2014-02-04 12:48:22 <ItsDom> so does a scriptPubKey have to start with a valid, assigned opcode?
200 2014-02-04 12:48:39 <sipa> define "have to"... according to which rule?
201 2014-02-04 12:49:35 <ItsDom> As, is an output invalid if it doesn't start with a valid op code (e.g. it wont get accepted into the blockchain)
202 2014-02-04 12:50:15 <sipa> no
203 2014-02-04 12:50:29 <sipa> outputs are only verified when they are attempted to be spent
204 2014-02-04 12:50:39 <sipa> from the point of view of a transaction, it's just a byte sequence
205 2014-02-04 12:51:12 <ItsDom> Okay, that makes sense. Thanks for that!
206 2014-02-04 13:28:34 <ItsDom> With the script commands, opcodes 1 - 75 labelled as N/A. What does the description "The next opcode is data to be pushed onto the stack" mean? Is it implying those values will only appear after PUSHDATA?
207 2014-02-04 13:45:03 <michagogo> cloud|ItsDom: Those mean "push this many bytes"
208 2014-02-04 13:45:17 <michagogo> cloud|14:39:15 <sipa> there's also implicit data pushes
209 2014-02-04 13:45:17 <michagogo> cloud|14:39:31 <sipa> for example 0x20 means "push the following 32 bytes"
210 2014-02-04 13:45:17 <michagogo> cloud|ItsDom:
211 2014-02-04 13:52:34 <ItsDom> michagogo|cloud: aaaah, that makes sense. Thanks for that. Another quick questions. Disabled commands (E.g. those marked in red on wiki) are they intepreted the same as e.g. OP_NOP1 - 10 and OP_INVALIDCODE in a script?
212 2014-02-04 13:59:37 <michagogo> cloud|ItsDom: iirc any opcode that doesn't exist causes the script to abort as a failure
213 2014-02-04 14:00:02 <michagogo> cloud|(Iirc the "disabled" opcodes are actually removed)
214 2014-02-04 14:01:06 <ItsDom> okay, given the when a transaction is sent out, the scriptPubKey isn't verified (as it's only checked on spending it later) does that mean it's possible to create a transaction with a removed op_code and it will be unspendable?
215 2014-02-04 14:02:17 <michagogo> cloud|Right.
216 2014-02-04 14:02:36 <michagogo> cloud|There's also opreturn, which explicitly has that behavior
217 2014-02-04 14:02:50 <michagogo> cloud|And is used to create provably unspendable outputs
218 2014-02-04 14:03:30 <ItsDom> yup. Okay. So OP_NOP1 - 7 are just ignored. What about OP_RESERVED1 and OP_RESERVED2?
219 2014-02-04 14:04:06 <michagogo> cloud|Keep in mind, one of these bytes in a script doesn't automatically invalidate it
220 2014-02-04 14:04:34 <michagogo> cloud|It's only actually executing the opcode that snorts
221 2014-02-04 14:04:38 <michagogo> cloud|Aborts
222 2014-02-04 14:04:58 <ItsDom> I'm aware. Obviously if someone includes a pubkey which contains a removed op_code, it'll all still work
223 2014-02-04 14:05:33 <michagogo> cloud|Right
224 2014-02-04 14:05:46 <michagogo> cloud|But it's not just in a pushdata that they may occur
225 2014-02-04 14:06:22 <ItsDom> Also, just to confirm, OP_1 - 16 (OP_x) simply pushes "x" onto the stack?
226 2014-02-04 14:06:22 <michagogo> cloud|If you have an if/else, you can have one of those codes in an unexecuted branch
227 2014-02-04 14:06:27 <michagogo> cloud|Yep
228 2014-02-04 14:06:53 <ItsDom> Any ideas about OP_RESERVED1 and OP_RESERVED2?
229 2014-02-04 14:07:12 <michagogo> cloud|For example, IF OP_RETURN ELSE CHECKSIG ENDIF
230 2014-02-04 14:07:40 <sipa> ItsDom: they're invalid
231 2014-02-04 14:08:00 <ItsDom> sipa: do they behave like a removed word (e.g. cause the entire thing to fail?)
232 2014-02-04 14:08:08 <michagogo> cloud|Yes
233 2014-02-04 14:08:15 <sipa> yes
234 2014-02-04 14:08:23 <sipa> i think they even cause failure inside an else branch
235 2014-02-04 14:08:33 <ItsDom> same with OP_RESERVED also?
236 2014-02-04 14:09:19 <sipa> ah, i'm wrong
237 2014-02-04 14:09:25 <sipa> OP_RESERVED is possible inside else
238 2014-02-04 14:09:54 <michagogo> cloud|sipa: I thought anything in the non-executed branch of an if may as well not exist?
239 2014-02-04 14:10:23 <michagogo> cloud|(Other than sigop count?)
240 2014-02-04 14:10:44 <michagogo> cloud|(And length, ofc)
241 2014-02-04 14:10:57 <sipa> yeah, i misread
242 2014-02-04 14:11:02 <ItsDom> sipa: so OP_RESERVED doesn't cause a failure in an else branch.... so what's it's purpose?
243 2014-02-04 14:11:17 <michagogo> cloud|ItsDom: ask Satoshi
244 2014-02-04 14:11:21 <sipa> ^
245 2014-02-04 14:11:31 <michagogo> cloud|Right now it's useless
246 2014-02-04 14:11:38 <ItsDom> okay. I'll send a carrier pigeon his way, thanks:)
247 2014-02-04 14:11:44 <michagogo> cloud|It acts as an op_return
248 2014-02-04 14:13:41 <ItsDom> Also, just to confirm, OP_PUBKEY, OP_PUBKEYHASH and OP_INVALIDOPCODE will also all behave like removed op codes if using in a transaction?
249 2014-02-04 14:17:23 <TD> sipa: are you still using sipa@ulyssis.org ?
250 2014-02-04 14:26:07 <sipa> TD: it's forwarded to gmail
251 2014-02-04 14:31:55 <ThomasV> TD: I guess I should have used the ML in the first place :P
252 2014-02-04 14:51:06 <stonecoldpat> petertodd: thumbs up for the old man hash smoke joke
253 2014-02-04 14:54:24 <sipa> can i hazh block?
254 2014-02-04 15:14:45 <ItsDom> Is there a reason why OP_VERIF doesn't appear as a removed op code despite it behaving like 1 (e.g. leads to invalid tx even if in unexecuting if branch)?
255 2014-02-04 15:53:16 <petertodd> ItsDom: It's because OP_VERIF matches (OP_IF <= opcode && opcode <= OP_ENDIF), yet there's no corresponding code for it, thus you end up at the default "return false" of the big switch in EvalScript() even when fExec != true
256 2014-02-04 15:53:52 <petertodd> ItsDom: as for the "reason", my guess would be it was some kind of mistake
257 2014-02-04 15:54:08 <petertodd> ItsDom: there's every reason to think scripting was a rush job
258 2014-02-04 15:58:42 <ItsDom> petertodd: thanks for the clarification. That's interesting to hear. I wonder why it was rushed (or at least comes across as rushed). Thanks again.
259 2014-02-04 15:59:53 <petertodd> ItsDom: e.g. how CHECKMULTISIG pops one too many values off the stack, or how CHECKSIG in general is so tightly integrated as to be not very useful, or the RETURN bug, or the complete lack of tests of any kind in the early sourcecode...
260 2014-02-04 16:17:24 <ItsDom> petertodd: that's really interesting to know. Are these things noted down anywhere?
261 2014-02-04 16:21:16 <torokun> petertodd: all those bugs you mention - are they slated to be fixed?
262 2014-02-04 16:21:31 <netg_> /2/3
263 2014-02-04 16:21:41 <sipa> torokun: they can't be fixed
264 2014-02-04 16:21:53 <sipa> (well, not without unreasonably much effort)
265 2014-02-04 16:22:08 <torokun> you could go to new op codes and deprecate the buggy ones
266 2014-02-04 16:22:21 <sipa> you can't just add new opcodes, that requires a hard fork
267 2014-02-04 16:22:54 <torokun> nobody can use new op codes until they're in the software
268 2014-02-04 16:23:04 <torokun> it shouldn't be a problem
269 2014-02-04 16:23:05 <sipa> define "in the software"
270 2014-02-04 16:23:18 <torokun> in the reference client
271 2014-02-04 16:23:27 <sipa> _everyone_ in the whole world needs to have an updated client that supports these new opcodes before _anyone_ can use them
272 2014-02-04 16:23:35 <sipa> that's an exceptionally hard thing to do
273 2014-02-04 16:23:39 <torokun> correct
274 2014-02-04 16:24:01 <sipa> and that's just not reasonable to do for these bugs that can easily be worked around
275 2014-02-04 16:24:01 <torokun> well, at least most would need it.
276 2014-02-04 16:24:24 <torokun> remaining clients would just reject those transactions but would be outvoted
277 2014-02-04 16:24:37 <sipa> you completely misunderstand how bitcoin's consensus works
278 2014-02-04 16:24:43 <sipa> there is no voting about validity
279 2014-02-04 16:24:58 <sipa> the only thing the mining system votes on is the _order_ of otherwise valid transactions
280 2014-02-04 16:25:08 <sipa> but they must be valid
281 2014-02-04 16:25:55 <torokun> so far as I understand, if you had 80% of the network on a new client and all those clients verified a block, the remaining 20% would have to follow it as it would be the longest chain, no?
282 2014-02-04 16:26:03 <sipa> no
283 2014-02-04 16:26:14 <sipa> the rule is: the longest _valid_ block chain is the one accepted
284 2014-02-04 16:26:25 <sipa> and valid is determined by every single client independently
285 2014-02-04 16:26:34 <torokun> so 20% would follow another chain then
286 2014-02-04 16:26:43 <sipa> which is a hard fork, and a disaster
287 2014-02-04 16:26:53 <sipa> otherwise miners could just 'vote' to give themself 100 BTC in every block
288 2014-02-04 16:27:56 <ItsDom> There's a list floating round somewhere for proposed changes for an inevitable hardfork - are they on that?
289 2014-02-04 16:28:06 <torokun> that's not what I meant
290 2014-02-04 16:28:33 <torokun> I meant that such a fork would not be a disaster if only a tiny number of clients forked
291 2014-02-04 16:28:47 <sipa> the number is irrelevant
292 2014-02-04 16:28:56 <sipa> their economic impact is what counts
293 2014-02-04 16:29:21 <sipa> if one of them includes mtgox or bitpay or coinbase or ..., it would be a disaster
294 2014-02-04 16:29:47 <ItsDom> is there still alerts in the protocol? do we have the private key to be able to send out alerts?
295 2014-02-04 16:29:58 <sipa> a few people do, and yes
296 2014-02-04 16:30:09 <sipa> though other clients could use their own alert key
297 2014-02-04 16:30:11 <ItsDom> could that not be employed to help with a fork?
298 2014-02-04 16:30:15 <sipa> no
299 2014-02-04 16:30:26 <sipa> well, it can be used to broadcast some emergency message
300 2014-02-04 16:30:35 <sipa> but for a hard fork, we need _every_ client to upgrade
301 2014-02-04 16:30:43 <sipa> for some changes, you'd even need to update every wallet
302 2014-02-04 16:30:50 <ItsDom> I understand. I was around for the last one:)
303 2014-02-04 16:31:01 <sipa> there's only been one hard fork ever
304 2014-02-04 16:31:24 <ItsDom> I thought there were 2: one with the overflow attack on transaction outputs, and one last year with the block size issue in the database?
305 2014-02-04 16:31:35 <torokun> and that was a disaster, right?
306 2014-02-04 16:31:37 <sipa> the first was just a soft fork
307 2014-02-04 16:31:54 <Goonie> Bitcoin Wallet 3.31 beta is available for testing! https://plus.google.com/u/0/b/101256420499771441772/101256420499771441772/posts/QknuUj6z4M2
308 2014-02-04 16:32:22 <ItsDom> sipa: forgive my ignorance - what's the difference between a hard and soft fork?
309 2014-02-04 16:32:27 <torokun> bitcoin still exists...
310 2014-02-04 16:32:30 <ItsDom> soft is optional and backwards compatible, hard isnt?
311 2014-02-04 16:32:53 <sipa> ItsDom: a soft fork means only things that were previously valid become invalid
312 2014-02-04 16:33:04 <sipa> ItsDom: and for those, it suffices that a majority of miners enforces the rule
313 2014-02-04 16:33:26 <sipa> a hard fork is anything that makes something valid that wasn't (a new opcode almost certainly has that effect)
314 2014-02-04 16:33:32 <torokun> if it happened, the fact is that people running an old client would almost certainly upgrade.
315 2014-02-04 16:33:46 <torokun> unless they disagreed with the change
316 2014-02-04 16:33:47 <ItsDom> torokun: they wouldn't know they had to upgrade
317 2014-02-04 16:34:00 <sipa> and a hard fork needs 100% of everyone to upgrade (not just miners, and not just 50%)
318 2014-02-04 16:34:37 <ItsDom> So soft vs is hard is basically client vs protocol?
319 2014-02-04 16:34:46 <sipa> both are protocol changes
320 2014-02-04 16:34:46 <torokun> there would be very few people disconnected enough not to hear the news
321 2014-02-04 16:35:11 <ItsDom> sipa: I thought the soft fork changed only the implementation (E.g. checks done on the transaction by the client, not the blockchain protocol)
322 2014-02-04 16:35:12 <sipa> there are also p2p changes, policy changes, ... but those don't really need a globally coordinated upgrade
323 2014-02-04 16:35:28 <sipa> ItsDom: a soft fork changes which blocks/transactions are valid
324 2014-02-04 16:35:45 <sipa> but in such a way that every old client still accepts anything that the new rules allow
325 2014-02-04 16:36:26 <ItsDom> Aaaah, so it is to do with backwards compatibility? (sorry for my constant oversimplifications)
326 2014-02-04 16:36:30 <sipa> yes
327 2014-02-04 16:36:39 <sipa> a soft fork is basically a backward compatible protocol change
328 2014-02-04 16:36:44 <lianj> like the p2sh change
329 2014-02-04 16:36:52 <sipa> BIP16, BIP30, BIP34 were soft forks
330 2014-02-04 16:37:29 <sipa> BIP50 was a hard fork
331 2014-02-04 16:37:38 <ItsDom> okay, I think I grasp it now. dammit, the more I learn about Bitcoin the more I realise I didn't know, and probably don't know.
332 2014-02-04 16:37:49 <sipa> normal forks resolve on their own
333 2014-02-04 16:38:01 <sipa> soft forks resolve once a majority of mining power upgrades
334 2014-02-04 16:38:06 <sipa> hard forks resolve once everyone upgrades
335 2014-02-04 16:38:25 <ItsDom> Okay, thanks for that.
336 2014-02-04 16:43:17 <petertodd> sipa, ItsDom: yeah, but remember you can add totally new opcodes, even a whole new scripting language, in a soft-fork with a bit of careful design. It's *risky*, but it certainely is possible to do a scriptv2.0 upgrade via a soft-fork.
337 2014-02-04 16:43:34 <sipa> petertodd: yup, i'm aware :)
338 2014-02-04 16:43:50 <sipa> though i wouldn't use that to make some incremental fixes
339 2014-02-04 16:44:53 <petertodd> sipa: I know, but people reading the chat log would get the wrong impression
340 2014-02-04 16:59:27 <jorick> just a quick question regarding mining, as the block header contains the hash of the transactions in it, does that mean that the header changes while mining (as new transactions are added to the pool)?
341 2014-02-04 17:04:04 <petertodd> jorick: correct
342 2014-02-04 17:13:11 <jorick> but doesnt that mean some of the "work" is lost? wouldnt it be better to disregard the new transactions?
343 2014-02-04 17:16:03 <petertodd> jorick: NO! mining is progress free, every hash you try has an equal chance of succeeding, independent of the others
344 2014-02-04 17:17:54 <jcorgan> jorick: mining is not a multi-step process toward a fixed solution; each trial hash is independent and has an equal probability of meeting difficulty, even if what is being hashed changes
345 2014-02-04 17:22:07 <jcorgan> sipa: in CKDpub, once Il is created from the HMAC output, that is where you'd test it for being 0 or >= curve order, before multiplying by G, correct?
346 2014-02-04 17:23:05 <jcorgan> both of those would be error conditions, meaning the chosen i index would be invalide?
347 2014-02-04 17:27:23 <sipa> jcorgan: you check Il for >= n
348 2014-02-04 17:27:36 <sipa> jcorgan: and you check the _sum_ after adding k for being zero
349 2014-02-04 17:27:45 <sipa> or in the public key, whether you end up with the point at infinity
350 2014-02-04 17:28:02 <jcorgan> excellent, thanks
351 2014-02-04 17:44:08 <samson_> I see there's a new version of the PolarSSL C library released which supports RIPEMD160, secp256k1 deterministic ECDSA (RFC 6979) - anyone used it ?
352 2014-02-04 18:57:29 <jcorgan> sipa: i've pushed some updates that hopefully capture your feedback for the CKDpriv and CKDpub implementations, as well as more examples in the README.md
353 2014-02-04 19:08:30 <sipa> ACTION spawns a discussion about coinjoin on the p2p protocol here
354 2014-02-04 19:08:46 <jgarzik> separate network
355 2014-02-04 19:08:48 <TD> ACTION doesn't really care if hidden service addresses are broadcast across the p2p network, it doesn't seem like much extra bandwidth
356 2014-02-04 19:09:03 <petertodd> maaku_: anyway, it's very important that we don't bag down wallets with Yet Another P2P System like people would end up doing w/ bitmessage-based schemes
357 2014-02-04 19:09:15 <BlueMatt> jgarzik/petertodd: I think this discussion could actually be more meta than just about coinjoin...the ability to have bitcoin peers acting on a specific protocol find each other and exchange messages is useful for several different cases
358 2014-02-04 19:09:29 <BlueMatt> so creating a more general system than "coinjoin uses its own p2p network" would be benificial
359 2014-02-04 19:09:30 <petertodd> BlueMatt: yeah, I was just about to say - e.g. archival nodes
360 2014-02-04 19:09:38 <BlueMatt> while I agree it probably shouldnt be on the bitcoin p2p network itself
361 2014-02-04 19:09:42 <sipa> i might agree to a general find-a-rendezvous-point mechanism in the p2p protocol
362 2014-02-04 19:09:49 <petertodd> BlueMatt: thing is, define "the bitcoin p2p network"
363 2014-02-04 19:09:55 <BlueMatt> well, ok, yes, theres that
364 2014-02-04 19:09:56 <sipa> but i don't think it should be used directly for broadcasting things to wallets
365 2014-02-04 19:10:18 <sipa> especially as wallets are generally only connected to it for short times
366 2014-02-04 19:10:19 <petertodd> BlueMatt: if you've got a system where nodes advertise "I do block stuff" and "oh, I also do coinjoin stuff", that's fine, and lets the two networks be separate where they need to be, not separate where they don't
367 2014-02-04 19:10:35 <petertodd> BlueMatt: (the non-CJ nodes don't need to pass around CJ messages at all...)
368 2014-02-04 19:10:58 <BlueMatt> petertodd: generally, yes, but note that we cant define lots of NODE_* flags for these kind of things
369 2014-02-04 19:11:05 <BlueMatt> because people will just want to use them generally
370 2014-02-04 19:11:13 <BlueMatt> and while we have lots of bits, we dont have /that/ many bits
371 2014-02-04 19:11:33 <petertodd> BlueMatt: main thing is that overall privacy/anonymity is helped when lots of different types of traffic are conglomorated when people volunteer to offer the bandwidth
372 2014-02-04 19:11:33 <TD> one thing that i'd like is a generic socket based plugin mechanism for bitcoind
373 2014-02-04 19:11:36 <BlueMatt> and, also, the |'ing of flags may not be ideal for all protocols (incl block holding)
374 2014-02-04 19:11:43 <sipa> adding an extra 'extraservices' P2P message is easy if necessary
375 2014-02-04 19:11:45 <petertodd> BlueMatt: right, hence why it's good to think ahead a bit
376 2014-02-04 19:11:50 <TD> where you can connect over a unix domain socket or something, and say "i claim service bit N and messages {a,b,c}, please route them to me"
377 2014-02-04 19:11:52 <petertodd> BlueMatt: though 64 of them isn't bad for now
378 2014-02-04 19:11:53 <sipa> BlueMatt: yeah, it's why i wanted host key signed messages on the network
379 2014-02-04 19:12:07 <TD> then you can easily offer additional services like chain indexing or archival or rendezvous points or whatever
380 2014-02-04 19:12:12 <TD> but it doesn't have to be tightly integrated with bitcoind
381 2014-02-04 19:12:22 <petertodd> TD: nah, for anti-spam tight integration is very useful
382 2014-02-04 19:12:40 <petertodd> TD: anti-spam via fees/coin-days works well here
383 2014-02-04 19:13:18 <pigeons> maybe transmit "stealth" S-addresses and nonces on this same platofrm as the coinjoin transactions?
384 2014-02-04 19:13:42 <petertodd> pigeons: stealth was carefully designed to be cj compat with no changes to the CJ protocol...
385 2014-02-04 19:14:14 <sipa> petertodd: huh?
386 2014-02-04 19:14:22 <sipa> where do you put the extra key?
387 2014-02-04 19:14:33 <petertodd> sipa: have you read the paper?
388 2014-02-04 19:14:38 <sipa> no
389 2014-02-04 19:14:41 <petertodd> sipa: then do so
390 2014-02-04 19:14:51 <sipa> yeah if i find the time
391 2014-02-04 19:15:18 <sipa> link? all i saw was some mailing list threads
392 2014-02-04 19:15:34 <petertodd> sipa: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03613.html
393 2014-02-04 19:15:49 <petertodd> sipa: cj compat is in the "requirements" section
394 2014-02-04 19:18:37 <sipa> extra advantage of using a separate output: no utxo impact
395 2014-02-04 19:18:51 <petertodd> sipa: ?
396 2014-02-04 19:19:12 <petertodd> sipa: oh, you mean vs. <ephemeral> OP_DROP (rest of script)
397 2014-02-04 19:19:14 <sipa> using OP_DROP means the extra data ends up in the UTXO set
398 2014-02-04 19:19:33 <petertodd> sipa: less privacy too, although long-term that kind of idea is more scalable
399 2014-02-04 20:02:05 <EasyAt> I have a question about addrman. There are 64 buckets for tried addresses and each bucket can contain 64 address. So, in theory you could have up to 4096 tried addresses cached. Correct?
400 2014-02-04 20:02:15 <flound1129> anyone know why the strace for bitcoind spams these futex errors?
401 2014-02-04 20:02:16 <flound1129> [pid 14094] futex(0xae205a4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 2824191, {1391544114, 887633000}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
402 2014-02-04 20:04:06 <sipa> EasyAt: correct
403 2014-02-04 20:04:43 <gmaxwell> also tried addresses when evicted go into the untried set.
404 2014-02-04 20:06:01 <EasyAt> Did you happen to read that paper from those researchers out of Switzerland. Information Propgation in the Bitcoin Network. They peered to all possible nodes they could discover and started relaying blocks immedietly. They cut the orphan rate in half for the 10k blocks that they were peering with everyone
405 2014-02-04 20:06:22 <sipa> EasyAt: yeah, i know the author :)
406 2014-02-04 20:06:37 <EasyAt> Neat, that was really cool
407 2014-02-04 20:08:36 <BlueMatt> speaking of which.... ,,(seen cdecker)
408 2014-02-04 20:08:36 <gribble> cdecker was last seen in #bitcoin-dev 1 year, 31 weeks, 5 days, 8 hours, 47 minutes, and 30 seconds ago: <cdecker> If you want to be notified take a look at http://www.bitcoinmonitor.net/services/
409 2014-02-04 20:08:40 <BlueMatt> damn
410 2014-02-04 20:08:57 <EasyAt> Is the purpose of diving the buckets into addresses ranges to make cybill attacks more expensive. As in you need to have IPs in many different ranges?
411 2014-02-04 20:10:17 <gmaxwell> EasyAt: that paper was really really disapointing.
412 2014-02-04 20:11:53 <gmaxwell> like, never realizing that a substantial portion of the delay is an intentional 100ms sleep in bitcoind message processing, or that they failed to observe that their proposed improvement had been implemented by luke-jr a long time previously.