1 2014-05-07 00:27:41 <seldegav1o> Hi, is anyone able to help me understand raw transactions, specifically how to parse Script?
2 2014-05-07 00:30:31 <seldegav1o> I'm trying to figure out what the input script does for this transaction (https://blockchain.info/tx/14be6fff8c6014f7c9493b4a6e4a741699173f39d74431b6b844fcb41ebb9984) and see that it starts with a 30. is the 30 an opcode or another value?
3 2014-05-07 02:58:02 <dabura667> Hi all, can anyone help me calculate the Y value for a compressed pubkey in python?
4 2014-05-07 02:58:14 <dabura667> I tried math.sqrt(x*x*x + 7) % P but it gives me 0.0
5 2014-05-07 03:00:18 <dabura667> for my test case I am using the following compressed pubkey 0x023cbf5edf6a8477b40e0ee9892b808b91b36247f03812f38b1b549c297a02bd8c
6 2014-05-07 03:54:34 <mappum> will any pools accept nonstandard transactions that have a sufficiently large fee?
7 2014-05-07 03:55:28 <Luke-Jr> mappum: Eligius generally, though there are still some rules to prevent spam etc
8 2014-05-07 03:56:19 <mappum> that's it? they are only 9% of the hashrate
9 2014-05-07 03:56:44 <mappum> i mean, if i just put txs out there with a 0.01+ fee will anyone automatically pick it up?
10 2014-05-07 03:57:19 <mappum> or do i need to manually negotiate it with pools
11 2014-05-07 03:57:26 <petertodd> mappum: non-standard transactions aren't relayed, so you need to manually negotiate
12 2014-05-07 03:58:05 <mappum> ah, so is the real approach to make a BIP and get it in core?
13 2014-05-07 03:58:14 <petertodd> that
14 2014-05-07 03:58:17 <petertodd> that's one approach
15 2014-05-07 03:58:33 <petertodd> what are you trying to do exactly?
16 2014-05-07 03:59:19 <mappum> p2p trade
17 2014-05-07 03:59:32 <petertodd> ah, what does your script look like?
18 2014-05-07 04:00:09 <mappum> well i haven't started developing anything, just thinking about it, but it would look like this: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
19 2014-05-07 04:00:50 <petertodd> I'd suggest making the application first on testnet; mainnet support can be arranged
20 2014-05-07 04:01:08 <mappum> hmm, but i would have to be able to get it accepted on altcoin chains, too
21 2014-05-07 04:01:39 <petertodd> mainnet_testnet:altcoin_testnet is possible - most alts have their own testnets without IsStandard()
22 2014-05-07 04:01:47 <petertodd> also last I checked namecoin doesn't actually have an IsStandard() rule
23 2014-05-07 04:01:53 <mappum> awesome, good to know
24 2014-05-07 04:03:21 <petertodd> the thing with IsStandard() is you only need a pool or two to change the rules to make formerly non-standard tx's useful
25 2014-05-07 04:05:19 <mappum> right, but right now it will take Eligius almost 2 hours per block
26 2014-05-07 04:05:24 <mappum> i guess that's not terrible
27 2014-05-07 04:09:59 <Luke-Jr> mappum: BIPs don't necessarily get anything in bitcoind; but they're a prerequisite in most cases
28 2014-05-07 04:10:19 <Luke-Jr> mappum: have you followed the cross-chain trading BIP discussions on the dev ML?
29 2014-05-07 04:10:42 <mappum> Luke-Jr: nope, is that recent?
30 2014-05-07 04:10:43 <petertodd> mappum: I suggested a safe way to remove the IsStandard() limits on scripts pretty much entirely there
31 2014-05-07 04:11:43 <Luke-Jr> mappum: somewhat recent, yes
32 2014-05-07 04:13:22 <petertodd> mappum: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05153.html
33 2014-05-07 04:14:16 <mappum> thanks
34 2014-05-07 04:41:09 <btcgjk> anyone need a hardware programmer?
35 2014-05-07 04:43:04 <petertodd> mappum: speaking of how easy it is to get strange tx's mined, here's 500uBTC for free: 26bde88051cbe283b68c5130f4e14c86e750e7eba79c3405ec7afb09bb924b95
36 2014-05-07 04:43:24 <petertodd> mappum: (writing some checkmultisig tests and wanted a starting point)
37 2014-05-07 04:45:50 <mappum> it's just OP_CHECKMULTISIG?
38 2014-05-07 04:46:13 <petertodd> yup, and the input that was spent is just OP_CHECKMULTISIG encoded as a p2sh tx
39 2014-05-07 04:47:40 <petertodd> (note that blockchain.info's display of the transaction is screwed up, displaying OP_CHECKMULTISIG for the p2sh redeemScript instead of displaying it as a pushdata op)
40 2014-05-07 05:49:16 <michagogo> cloud|seldegav1o: the input script consists of two data pushes. First the signature and then the public key. 30 is the first byte of the signature. Blockchain.info doesn't show it, but before the signature and before the pubkey (the one starting with 04) are data push opcodes.
41 2014-05-07 05:53:56 <zone117x> why is it that sometimes when checking the status of a block's coinbase tx, the results of gettransaction are odd?
42 2014-05-07 05:54:14 <zone117x> odd as in they contain all the usual fields except the blockhash and the details array is empty
43 2014-05-07 05:54:19 <zone117x> and the confirmatoins field is -1
44 2014-05-07 05:54:40 <zone117x> I'm assuming it means the block was orphaned in just weird way?
45 2014-05-07 05:55:17 <phantomcircuit> i would not advice assuming anything there
46 2014-05-07 06:11:22 <michagogo> cloud|petertodd: what's -46?
47 2014-05-07 06:19:05 <michagogo> cloud|Oh, I see -- it's op_checkmultisig. Where did -46 come from?
48 2014-05-07 06:19:34 <michagogo> cloud|Hm, can checkmultisig do a 0-of-n?
49 2014-05-07 06:19:57 <mapppum> michagogo|cloud: that's what i'm trying to do, it appears not
50 2014-05-07 06:20:15 <michagogo> cloud|Or do we need to figure out how to sign the tx with an arbitrary key?
51 2014-05-07 06:20:16 <justanotheruser> mapppum: invalid?
52 2014-05-07 06:20:23 <mapppum> yep
53 2014-05-07 06:20:54 <justanotheruser> michagogo|cloud: I would assume with an 0 of n (if it was valid) the scriptsig wouldn't contain any keys
54 2014-05-07 06:21:05 <mapppum> i'm trying to peer with a node that accepts nonstandard txs, but maybe i'm doing that wrong
55 2014-05-07 06:21:17 <michagogo> cloud|justanotheruser: it would contain n keys
56 2014-05-07 06:21:24 <justanotheruser> mapppum: testnet or mainnet
57 2014-05-07 06:21:32 <mapppum> mainnet
58 2014-05-07 06:21:32 <michagogo> cloud|No keys would be 0-of-0
59 2014-05-07 06:21:35 <justanotheruser> michagogo|cloud: I mean signatures
60 2014-05-07 06:21:41 <michagogo> cloud|Right
61 2014-05-07 06:22:18 <michagogo> cloud|If 0-of-n is possible, which i'd assume is not the case, that would be no-sigs
62 2014-05-07 06:22:22 <justanotheruser> I wonder if 2 of 1 is valid
63 2014-05-07 06:22:29 <michagogo> cloud|No
64 2014-05-07 06:22:36 <michagogo> cloud|Pretty sure it's not
65 2014-05-07 06:23:01 <mapppum> eyeballing the code it looks like 0-of-0 should work
66 2014-05-07 06:23:04 <michagogo> cloud|Unfortunately, I'm not at my computer atm, and I'll have a meeting soon
67 2014-05-07 06:23:16 <justanotheruser> I wonder what other transactions have questionable validity
68 2014-05-07 06:23:26 <mapppum> the scriptsig should just be 0001000100, right?
69 2014-05-07 06:23:30 <michagogo> cloud|So I probably won't be the it's to get it
70 2014-05-07 06:23:38 <michagogo> cloud|The first*
71 2014-05-07 06:23:45 <mapppum> *OP_0 0x00 0x00
72 2014-05-07 06:24:22 <michagogo> cloud|GL
73 2014-05-07 06:30:34 <petertodd> michagogo|cloud: yes it can: https://github.com/bitcoin/bitcoin/pull/3860
74 2014-05-07 06:31:25 <justanotheruser> petertodd: what about 2 of 1? Any idea?
75 2014-05-07 06:31:46 <petertodd> justanotheruser: that's supposed to fail immediately
76 2014-05-07 06:31:56 <petertodd> I'm actually writing some unit tests right now to verify that
77 2014-05-07 06:33:35 <mapppum> so 0 0 0 is supposed to work, why is it getting rejected? :(
78 2014-05-07 06:33:36 <justanotheruser> petertodd: cool. Be sure to include -1 of 1 :p
79 2014-05-07 06:33:44 <petertodd> yeah, I'm doing that too
80 2014-05-07 06:33:56 <justanotheruser> Unless it automatically evaluates m of n to unsigned ints
81 2014-05-07 06:34:20 <justanotheruser> mapppum: on the testnet or main net?
82 2014-05-07 06:34:38 <mapppum> main
83 2014-05-07 06:34:45 <petertodd> justanotheruser: the n and m args are converted from bytes to ints via CastToBigNum(), so they are evaluated as signed
84 2014-05-07 06:34:54 <mapppum> i'm supposedly peering with a node that accepts everything
85 2014-05-07 06:34:57 <petertodd> justanotheruser: that'd be a fun bug in an alt-implementation though...
86 2014-05-07 06:35:08 <petertodd> mappum: the one from the wiki?
87 2014-05-07 06:35:13 <mapppum> yeah
88 2014-05-07 06:35:22 <petertodd> mappum: I'm not sure that one actually ever gets to eligius
89 2014-05-07 06:35:33 <justanotheruser> petertodd: are you implying alts would make a change that big?
90 2014-05-07 06:35:42 <petertodd> justanotheruser: accidentally, sure
91 2014-05-07 06:36:14 <mapppum> well how does the send-to-network logic work? bitcoind says "TX Rejected", idk if it tries every peer
92 2014-05-07 06:36:35 <petertodd> mappum: oh, then it's being rejected locally - you need to disable IsStandard() locally too
93 2014-05-07 06:37:11 <justanotheruser> mapppum: you should try this on the test net, but if you don't want to, use the free relay policy node
94 2014-05-07 06:38:27 <mapppum> so i just rebuild with isstandard disabled?
95 2014-05-07 06:38:33 <petertodd> yup
96 2014-05-07 06:39:25 <justanotheruser> Is eligius still the only node connected to the free relay policy node?
97 2014-05-07 06:39:31 <justanotheruser> *miner node
98 2014-05-07 06:39:38 <petertodd> probably
99 2014-05-07 06:44:02 <michagogo> cloud|As an experiment, I tried manually putting this together: 0100000001954b92bb09fb7aec05349ca7ebe750e7864ce1f430518cb683e2cb5180e8bd2600000000050001000100ffffffff010000000000000000016a00000000
100 2014-05-07 06:44:20 <michagogo> cloud|eligius duesn't seem to like it
101 2014-05-07 06:44:23 <michagogo> cloud|doesn't*
102 2014-05-07 06:44:50 <petertodd> michagogo|cloud: I already spent it :)
103 2014-05-07 06:44:54 <michagogo> cloud|ah
104 2014-05-07 06:44:57 <michagogo> cloud|that'll do it :P
105 2014-05-07 06:45:06 <justanotheruser> michagogo|cloud: how do you know they don't like it (out of curiosity)
106 2014-05-07 06:45:26 <michagogo> cloud|justanotheruser: the transaction was rejected when I sent it to them
107 2014-05-07 06:45:27 <michagogo> cloud|g2g
108 2014-05-07 06:45:29 <mapppum> damn, i wanted to grab that, i lost because my own node betrayed me
109 2014-05-07 06:45:42 <justanotheruser> How much was it?
110 2014-05-07 06:46:01 <petertodd> mapppum: here's another: eef973bd1d44384cec01e91727b783bd58b4eac6efe318d0db4dd0fd678ae8a3
111 2014-05-07 06:46:14 <petertodd> mapppum: (p2sh version of OP_CHECKMULTISIG)
112 2014-05-07 06:53:49 <mapppum> petertodd: wait, so what hashes to that?
113 2014-05-07 06:54:13 <petertodd> mapppum: bitcoind decodescript ae
114 2014-05-07 06:54:37 <petertodd> mapppum: this might be useful: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2sh-txout.py
115 2014-05-07 06:56:31 <mapppum> ah, i see. i though HASH160 was just ripemd160
116 2014-05-07 06:56:40 <petertodd> yup
117 2014-05-07 06:57:40 <petertodd> unrelated: if satoshi had included a SIGHASH_DONT_SIGN_TXID then OP_CODESEPARATOR would actually be quite useful for gait's key signing stuff, among other things
118 2014-05-07 08:03:52 <survic> petertodd: must be anoying being Satoshi. you'd be kicking yourself for not adding feature X, or silently screaming at the current developers for not doing things your way.
119 2014-05-07 08:05:20 <jcorgan> or marveling at how your "fun" escaped to become what it is today :)
120 2014-05-07 08:09:17 <proxy1> is there any documentation available on cross compiling the windows qt binary in linux using mingw?
121 2014-05-07 08:11:00 <wumpus> proxy1: I'd suggest using gitian, which is the system used to build the release binaries
122 2014-05-07 08:11:19 <wumpus> proxy1: it does exactly that, but automates all the steps like building dependencies
123 2014-05-07 08:11:39 <proxy1> thanks very much ill check it out
124 2014-05-07 08:13:19 <wumpus> see https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/README.md and doc/release-process.md
125 2014-05-07 10:28:19 <sipa> dabura667: you need a modular square root, not a real one
126 2014-05-07 10:30:56 <dabura667> sipa: thanks. I figured it out with help from someone on #darkwallet
127 2014-05-07 10:50:34 <kdomanski_> sipa: what do you think about replacing every ambiguous type (int, unsigned int) with unambiguous type wherever it makes sense and replacing every C-style cast with static_cast/reinterpret_cast ?
128 2014-05-07 10:51:21 <sipa> kdomanski_: sure
129 2014-05-07 10:51:37 <sipa> kdomanski_: though i find c++ style casts a bit annoyingly long to read often
130 2014-05-07 10:52:12 <kdomanski_> yeah, but C-style are difficult to grep for and there's going to be a lot of casts to remove
131 2014-05-07 10:52:32 <sipa> but at least all serializable integer fields in classes should be int/uint 8/16/32/64
132 2014-05-07 10:52:40 <kdomanski_> yeah
133 2014-05-07 10:52:47 <sipa> char may be an exception...
134 2014-05-07 12:20:52 <wumpus> I don't really like all-over-the-place changes that much
135 2014-05-07 12:21:36 <wumpus> let's not go over the top with replacing everything
136 2014-05-07 12:22:19 <wumpus> if you need to do it in the scope of solving another issue, sure, but changing just for the sake of some stylism, meh
137 2014-05-07 12:24:52 <wumpus> replacing int/unsigned int/etc with sized types makes sense for serialization, and network data structures, but please don't change every single one
138 2014-05-07 12:26:30 <sipa> wumpus: wild suggestion: introduce new types in serialize.h for the 8 int types, and have only those serializable
139 2014-05-07 12:26:53 <sipa> and if you need a serializable int, you must use those
140 2014-05-07 12:28:17 <wumpus> sipa: I'm not sure; how would that be different than the stdint types?
141 2014-05-07 12:29:06 <sipa> it would prevent you from writing an int somewhere and expecting a consistent serialization for it
142 2014-05-07 12:29:58 <wumpus> right, but can't we force using the (sized) stdint types?
143 2014-05-07 12:30:13 <sipa> those are typedefs
144 2014-05-07 12:31:15 <wumpus> right, so if you want to serialize an values you'd have to use
145 2014-05-07 12:31:18 <gavinandresen> Yet Another Integer Definition Just Because We're Very Special seems like a bad idea.
146 2014-05-07 12:31:39 <gavinandresen> int64, int64t, long long, qint64 â¦â¦.. btc_int64 ???
147 2014-05-07 12:31:41 <wumpus> so serialization would look like this: out << int16(x) << int32(y) << int64(t)
148 2014-05-07 12:31:49 <wumpus> that'd be sort of nice
149 2014-05-07 12:32:08 <wumpus> not too distant from just using out.writeInt16() out.writeInt32() like in the good old days tho :)
150 2014-05-07 12:32:13 <sipa> wumpus: that's another way
151 2014-05-07 12:32:42 <wumpus> because we don't really want type overloading here, we want to be explicit
152 2014-05-07 12:33:06 <sipa> but i mean like class btc_int64 : public int64 { implement serialize... }
153 2014-05-07 12:33:32 <sipa> so fields of structs that have a defined serialization would use those types, and not wrap on serialization
154 2014-05-07 12:35:00 <wumpus> when wrapping on serialization (or having specific functions for specific bit sizes) would move the specification to serialization time, instead of having it potentially somewhere else where the field is defined
155 2014-05-07 12:35:11 <sipa> indeed
156 2014-05-07 12:35:52 <sipa> we need int58_t
157 2014-05-07 12:36:08 <wumpus> having our own integer type dfinitions sounds like a bottomless pit (you'd want to implement all operators too?)
158 2014-05-07 12:36:13 <wumpus> hehe
159 2014-05-07 12:36:21 <sipa> no, just derive from the existing ones
160 2014-05-07 12:36:35 <t7> templated sized types?
161 2014-05-07 12:36:45 <t7> Int<58>
162 2014-05-07 12:36:51 <wumpus> can you derive from base types like int?
163 2014-05-07 12:36:56 <sipa> i assume so?
164 2014-05-07 12:37:49 <sipa> but perhaps explicit serializer wrappers is cleaner
165 2014-05-07 12:37:55 <wumpus> I don't think so
166 2014-05-07 12:37:58 <wumpus> yes, agreed
167 2014-05-07 12:39:23 <sipa> seems you can't, indeed
168 2014-05-07 12:43:53 <kdomanski> lol, I found beauties like assert(nSize >= 0) where nSize should be unsigned anyway
169 2014-05-07 12:44:14 <wumpus> well it doesn't hurt...
170 2014-05-07 12:45:25 <epscy> sanity check
171 2014-05-07 12:45:44 <epscy> it's good to do once in a while at certain points
172 2014-05-07 12:46:05 <sipa> assert(sizeof(int) >= 0)
173 2014-05-07 12:46:14 <epscy> heh
174 2014-05-07 12:46:16 <survic> assert(1 > 0)
175 2014-05-07 12:46:46 <SomeoneWeird> assert(0 == 0) ??
176 2014-05-07 12:46:50 <wumpus> heh https://github.com/bitcoin/bitcoin/issues/4081
177 2014-05-07 12:48:03 <kdomanski> it makes sense if nSize is int
178 2014-05-07 12:48:19 <kdomanski> but if I change it to uint64_t...nope
179 2014-05-07 12:49:20 <wumpus> be careful with overflows/underflows and such if you change signed to unsigned... indeed, n>=0 is always true for unsigned numbers but it may get veeery large :p
180 2014-05-07 12:50:31 <kdomanski> the I would add an assert after every operation that would yield negative size
181 2014-05-07 12:50:33 <kdomanski> *then
182 2014-05-07 12:51:27 <kdomanski> not to mention the number of implicit conversions and signed-to-unsigned comparisons in the current codebase that scares the crap out of me
183 2014-05-07 12:55:10 <survic> the monsanto of the nasal voles.
184 2014-05-07 12:55:14 <survic> uh.
185 2014-05-07 12:56:42 <sipa> kdomanski: please don't change semantics at the same time
186 2014-05-07 12:57:23 <sipa> changing int types for equivalent and less ambiguous ones where it makes sense is one thing
187 2014-05-07 12:57:31 <wumpus> sipa: agreed
188 2014-05-07 12:57:41 <kdomanski> please elaborate
189 2014-05-07 12:57:50 <CheckDavid> Lol survic
190 2014-05-07 12:58:00 <sipa> but changes to signed/unsigned may have far more serious results
191 2014-05-07 12:58:14 <wumpus> 'equivalent' is the keyword here
192 2014-05-07 12:58:27 <sipa> and yes, that can be improved too, but that is a semantics change
193 2014-05-07 12:58:28 <wumpus> we don't actually want the code to change, but we do want to clarify it
194 2014-05-07 12:58:45 <kdomanski> ok, it's great that you mentioned it
195 2014-05-07 12:59:12 <kdomanski> because I already changed that in a few instances
196 2014-05-07 12:59:13 <kdomanski> :P
197 2014-05-07 12:59:15 <wumpus> (at least concerning the serialization and other sooper serious consensus stuff)
198 2014-05-07 13:03:08 <kdomanski> actually, the only places where I wanted to change signedness were functions CDataStream::write CDataStream::ignore and CDataStream::where the parameter is nSize
199 2014-05-07 13:07:28 <kdomanski> if think the parameter always takes an unsigned value, most often the result of a sizeof()
200 2014-05-07 13:10:29 <wumpus> that can always be changed later
201 2014-05-07 13:10:39 <wumpus> better to focus on one thing at a time
202 2014-05-07 13:10:48 <kdomanski> k
203 2014-05-07 13:12:46 <sipa> a pr "change some types by strictly equivalent types" is easier to review than "change some types
204 2014-05-07 13:17:32 <hearn> i hate fees. they make everything so complicated
205 2014-05-07 13:37:01 <kdomanski> sooooo...what size is a 'long
206 2014-05-07 13:37:13 <kdomanski> ' eqivalent to?
207 2014-05-07 13:38:50 <kdomanski> lol
208 2014-05-07 13:39:38 <wumpus> at least: 32 bit on x86, 64 bit on amd64
209 2014-05-07 13:40:05 <kdomanski> so it's basically an 'int'
210 2014-05-07 13:40:11 <sipa> int is 32-bit on both
211 2014-05-07 13:40:15 <wumpus> it's the type that causes the most problems
212 2014-05-07 13:40:19 <kdomanski> right
213 2014-05-07 13:40:24 <sipa> but ehm
214 2014-05-07 13:40:47 <sipa> that must mean we have no long's anywhere in serializable data structures?
215 2014-05-07 13:42:23 <kdomanski> probably, yeah
216 2014-05-07 13:43:21 <wumpus> yeah I don't think so
217 2014-05-07 13:56:46 <ematiu> Is there anyway to use SPV with stealth addresses? Is it possible to setup bloom filters to include addresses generated by a stealth address? (or the OP_RETURN for the nounce)
218 2014-05-07 14:22:37 <kdomanski> https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L425
219 2014-05-07 14:22:40 <kdomanski> goddamn satoshi
220 2014-05-07 14:24:07 <joedoe-> could you please point me to difficulty retarget settings in source code?
221 2014-05-07 14:25:02 <michagogo> cloud|joedoe-: don't know where it is off the top of my head, but try grepping for 2016
222 2014-05-07 14:25:18 <joedoe-> ok thanks
223 2014-05-07 14:26:06 <sipa> that won't help
224 2014-05-07 14:26:31 <joedoe-> yeah all I want is GetNetworkHashPS()
225 2014-05-07 14:26:59 <sipa> joedoe-: that has nothing to do with the difficulty computation...
226 2014-05-07 14:27:09 <sipa> well, they compute something similar
227 2014-05-07 14:27:21 <sipa> but the difficulty retargetting is a network rule that can't be changed
228 2014-05-07 14:27:48 <sipa> getnetworkhashps is a utility function that is intended for human consumption
229 2014-05-07 14:28:00 <sipa> the protocol internally doesn't have a 'difficulty' concept, only a target
230 2014-05-07 14:28:03 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1228
231 2014-05-07 14:28:10 <sipa> that's the consensus code
232 2014-05-07 14:28:55 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/rpcmining.cpp#L57
233 2014-05-07 14:28:59 <sipa> that's getnetworkhashps
234 2014-05-07 14:31:36 <fun> hey
235 2014-05-07 14:31:56 <fun> when compiling btc 0.9 is it best to use Berkeley DB 4.8.30.tar.gz, with AES encryption (22M) ?
236 2014-05-07 14:32:11 <sipa> we don't use bdb's built-in encryption
237 2014-05-07 14:32:27 <joedoe-> ok static const int64_t nTargetTimespan = 14 * 24 * 60 * 60; // two weeks
238 2014-05-07 14:32:30 <joedoe-> this is an answer
239 2014-05-07 14:32:31 <fun> oki then Berkeley DB 4.8.30NC.tar.gz , without encryption (22M) ?
240 2014-05-07 14:32:38 <sipa> fun: either is fine
241 2014-05-07 14:32:45 <fun> cool
242 2014-05-07 14:33:09 <fun> sipa any plans to move to 5.1? also if 5.1 is used what are the issues?
243 2014-05-07 14:33:22 <fun> maybe there is some url that talks about it
244 2014-05-07 14:33:27 <sipa> fun: no
245 2014-05-07 14:33:33 <sipa> fun: use whatever you like
246 2014-05-07 14:33:49 <sipa> fun: release binaries use 4.8 so that wallet files remain backward compatible
247 2014-05-07 14:33:56 <fun> I read 5.1 means u cant move wallet to another btc install
248 2014-05-07 14:34:24 <sipa> if you open the wallet file with a newer bdb version, it is upgraded to the new format, and the old version can't read it anymore
249 2014-05-07 14:34:46 <sipa> that's why released binaries always use the same version, but you can use whatever you like
250 2014-05-07 14:35:03 <fun> ty
251 2014-05-07 14:39:59 <fun> sipa then ../dist/configure --enable-cxx and make and install? thing is many people want to use 0.9 but 4.8 is missing on latest linux :D
252 2014-05-07 14:40:16 <sipa> fun: then use 5.1
253 2014-05-07 14:40:30 <sipa> or install a backport of 4.8
254 2014-05-07 14:41:25 <fun> sudo add-apt-repository ppa:bitcoin/bitcoin this?
255 2014-05-07 14:41:45 <fun> good idea :)
256 2014-05-07 14:41:56 <sipa> i personally have used 5.1 for years now
257 2014-05-07 14:42:30 <fun> sipa ok using 5.1 have any consequences? like some apps for btc might still rely on 4.8?
258 2014-05-07 14:42:40 <fun> i would totally prefer 5`1 :D
259 2014-05-07 14:43:08 <sipa> no
260 2014-05-07 14:43:16 <fun> ok then :)
261 2014-05-07 14:43:16 <sipa> just use 5.1
262 2014-05-07 14:43:30 <sipa> it just means you can't use release binaries anymore
263 2014-05-07 14:43:36 <sipa> unless you downgrade the wallet file again
264 2014-05-07 14:43:53 <sipa> (db5.1_dump wallet51.dat | db4.8_load wallet48.dat)
265 2014-05-07 14:45:40 <fun> yes thats cool
266 2014-05-07 14:48:23 <fun> configure.ac:689: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_C
267 2014-05-07 14:49:11 <michagogo> cloud|Hm, does pywallet care about 4.8 vs 5.1?
268 2014-05-07 14:49:12 <fun> compiling on ubuntu 14.04
269 2014-05-07 14:49:26 <michagogo> cloud|fun: warnings are usually ignorable
270 2014-05-07 14:49:46 <michagogo> cloud|Unless something's not working
271 2014-05-07 14:49:51 <fun> what if its something important?
272 2014-05-07 14:50:03 <sipa> fun: it's not; it's just using an old name...
273 2014-05-07 14:50:14 <sipa> feel free to fix it, if you understand the problem
274 2014-05-07 14:50:16 <michagogo> cloud|fun: if it's important it'll probably be an error
275 2014-05-07 14:50:46 <fun> ok fine however it also stops after it, I installed automake maybe I need something else as well?
276 2014-05-07 14:50:53 <michagogo> cloud|And reading the message, sounds like it knows what you mean
277 2014-05-07 14:51:01 <michagogo> cloud|fun: was that autogen.sh?
278 2014-05-07 14:51:13 <fun> yes
279 2014-05-07 14:51:16 <michagogo> cloud|Run configure now.
280 2014-05-07 14:51:19 <sipa> read doc/build-unix.md please
281 2014-05-07 14:51:23 <michagogo> cloud|(With any options you want)
282 2014-05-07 14:51:35 <michagogo> cloud|And yeah, read that if you haven't
283 2014-05-07 14:52:12 <fun> :)
284 2014-05-07 14:52:12 <fun> ok I read it and going to fix it
285 2014-05-07 15:00:04 <fun> what is txindex=1 for?
286 2014-05-07 15:00:28 <fun> ok I got it
287 2014-05-07 15:00:36 <fun> it indexes all transactions locally
288 2014-05-07 15:01:29 <fun> http://bitcoin.stackexchange.com/questions/10090/how-to-get-an-addresss-balance-with-the-bitcoin-client
289 2014-05-07 15:01:30 <michagogo> cloud|fun: it keeps an index of all transactions and their locations in the blockchain in memory
290 2014-05-07 15:01:50 <michagogo> cloud|So it lets you use getrawtransaction on any transaction
291 2014-05-07 15:02:27 <michagogo> cloud|Um. s/in memory/by txid/
292 2014-05-07 15:02:34 <michagogo> cloud|I have no idea how that happened
293 2014-05-07 15:03:39 <fun> While it is fairly common that people reuse addresses for deposits or donations, doing so is harmful to yourself and others using Bitcoin in a number of ways which are outside the scope of this question.
294 2014-05-07 15:03:42 <fun> how come?
295 2014-05-07 15:03:55 <fun> I just read more comments there lol
296 2014-05-07 15:04:07 <michagogo> cloud|fun: short answer: because transactions can be linked together
297 2014-05-07 15:04:16 <fun> oki privacy
298 2014-05-07 15:04:24 <michagogo> cloud|Yes, privacy
299 2014-05-07 15:04:43 <pigeons> privacy leaks and some implementations have problems making key recovery easier with as few as 2 signatures to compare from the same key
300 2014-05-07 15:04:52 <fun> maybe add privacy button to QT? and that button then deletes all used addresses
301 2014-05-07 15:05:03 <michagogo> cloud|But not just yours. If you reuse addresses, you don't just reduce your privacy, they reduce the privacy of everyone you transact with
302 2014-05-07 15:05:05 <fun> so once u use it once its deleted :)
303 2014-05-07 15:05:21 <michagogo> cloud|And also, yes, there are other reasons
304 2014-05-07 15:05:24 <fun> that can be handy addition
305 2014-05-07 15:05:45 <sipa> fun: you don't want to delete keys; you just want to discourage reusing them
306 2014-05-07 15:05:49 <mr_burdell> fun: we added something like that in electrum and it's very confusing to users
307 2014-05-07 15:05:53 <sipa> fun: which is what recent bitcoin-qt does
308 2014-05-07 15:06:24 <mr_burdell> we get a lot of users asking where their addresses went and if they can still spend to them or not
309 2014-05-07 15:06:39 <mr_burdell> and they're worried that someone could send them money and they won't get it
310 2014-05-07 15:06:40 <michagogo> cloud|Like what pigeons just said -- if you have software broken in a certain way, as Android was at one point IIRC, when you spend two sets of funds sent to an address, you could reveal the privkey
311 2014-05-07 15:06:55 <fun> lol yes cause they think address is safe where money are :D
312 2014-05-07 15:07:13 <fun> assosiation with post box I think
313 2014-05-07 15:07:23 <sipa> yeah, calling it an address was a big mistake
314 2014-05-07 15:07:32 <sipa> it should have been called invoice id or something
315 2014-05-07 15:07:45 <fun> or address of the wallet
316 2014-05-07 15:07:49 <sipa> ...
317 2014-05-07 15:07:51 <fun> something like that
318 2014-05-07 15:08:02 <sipa> no, not at all
319 2014-05-07 15:08:08 <fun> why not?
320 2014-05-07 15:08:09 <mr_burdell> invoice id makes sense
321 2014-05-07 15:08:10 <michagogo> cloud|And also, when you spend funds sent to an address, you reveal the public key
322 2014-05-07 15:08:25 <sipa> the problem is that calling it an address makes people reason in terms of "balance stored on an address"
323 2014-05-07 15:08:31 <michagogo> cloud|Which right now isn't a big deal
324 2014-05-07 15:08:40 <sipa> while it should be balance of a wallet - let the wallet manage which keys are used to proctect the coin
325 2014-05-07 15:09:02 <fun> sipa well usually say you order pizza to certain address - its like a co ordinates and pizza is then stored in the house
326 2014-05-07 15:09:19 <fun> idea is to let people know its wallet that stores keys to the coins
327 2014-05-07 15:09:25 <fun> not the address lol
328 2014-05-07 15:09:33 <sipa> such lol
329 2014-05-07 15:09:48 <michagogo> cloud|But in the theoretical future, an attack or QC may weaken ECDSA and that will only affect known public keys
330 2014-05-07 15:10:15 <michagogo> cloud|(Er, I may not have explained that optimally)
331 2014-05-07 15:10:43 <fun> well its seems simple someone can release qt where address is renamed into something else and check the uptake
332 2014-05-07 15:10:53 <sipa> won't work now
333 2014-05-07 15:11:06 <sipa> you won't change how people think
334 2014-05-07 15:11:20 <fun> people say heck its hack no addresses lol
335 2014-05-07 15:11:21 <fun> haha
336 2014-05-07 15:11:33 <jgarzik> mr_burdell, is your first name George, perchance? :)
337 2014-05-07 15:11:55 <sipa> fun: everything is a joke to you?
338 2014-05-07 15:11:57 <mr_burdell> jgarzik: I went to gatech
339 2014-05-07 15:12:03 <fun> sipa lol its funny
340 2014-05-07 15:12:08 <sipa> k
341 2014-05-07 15:12:11 <fun> I work with customers alot
342 2014-05-07 15:12:22 <jgarzik> mr_burdell, as did many :)
343 2014-05-07 15:12:23 <sipa> my condolences
344 2014-05-07 15:12:29 <fun> try working in customer service then you might see :)
345 2014-05-07 15:12:44 <fun> but ok I believe in human potential
346 2014-05-07 15:12:54 <fun> so maybe I try to release some new QT soon
347 2014-05-07 15:14:05 <fun> mr_burdell: have you seen wallet that allows to trade btc from it?
348 2014-05-07 15:14:22 <fun> I saw something like that on forums recently
349 2014-05-07 15:14:42 <mr_burdell> fun: in what sense? most exchanges have a "wallet" that you can exchange from
350 2014-05-07 15:14:59 <fun> its a QT and you can also directly trade from it
351 2014-05-07 15:15:17 <fun> without having to go to exchanges webpage
352 2014-05-07 15:17:25 <fun> "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications" hmm
353 2014-05-07 15:17:34 <fun> I simply used git clone
354 2014-05-07 15:17:48 <fun> is it simpy an overcautious message?
355 2014-05-07 15:17:48 <mr_burdell> fun, you have to "checkout v0.9.1"
356 2014-05-07 15:17:54 <fun> how?
357 2014-05-07 15:18:00 <mr_burdell> after clone
358 2014-05-07 15:18:03 <mr_burdell> cd bitcoin
359 2014-05-07 15:18:09 <mr_burdell> git checkout v0.9.1
360 2014-05-07 15:19:54 <fun> cool ty
361 2014-05-07 15:20:17 <fun> mr_burdell: so yes do you also plan to add trading features in the electrum?
362 2014-05-07 15:20:28 <mr_burdell> no, I don't plan to
363 2014-05-07 15:20:37 <fun> oki
364 2014-05-07 15:20:37 <mr_burdell> someone added a coinbase integration though
365 2014-05-07 15:21:00 <mr_burdell> but it's only buying
366 2014-05-07 15:24:20 <fun> oki time to eat, thanks for the tips :D
367 2014-05-07 15:38:46 <dabura667> anyone know a website where I can push non-standard raw transactions?
368 2014-05-07 15:44:12 <petertodd> dabura667: http://eligius.st/~wizkid057/newstats/pushtxn.php
369 2014-05-07 15:44:53 <dabura667> rejected...
370 2014-05-07 15:45:02 <dabura667> weird...
371 2014-05-07 15:45:03 <petertodd> 0bin it?
372 2014-05-07 15:45:11 <dabura667> ok
373 2014-05-07 15:47:27 <petertodd> dabura667: and by 0bin, I mean pastebin so I can look at it
374 2014-05-07 15:47:48 <dabura667> http://pastebin.com/pYeNwpUJ
375 2014-05-07 15:48:08 <petertodd> no, actually I'm interested in the raw hex
376 2014-05-07 15:48:14 <dabura667> oh ok
377 2014-05-07 15:48:34 <dabura667> http://pastebin.com/4nqMd8sC
378 2014-05-07 15:48:37 <petertodd> (0bin.net >> pastebin IMO for being encrypted)
379 2014-05-07 15:52:49 <petertodd> I succesfully pushed through the op_return part: 01000000011058c1c7d8a90b2cfd5671f19a62cde4a715fe3ddb878fbfe761c6e721a16d23010000006b483045022100e58e97e627cf305302cd153923070851be7ae612e28c81535d7298f848f93f2a02203790597caa12508bb878d9de633161a2eb4ffb35886ef04c8b51284ad7ae6536012102e5a25e351e95c52abc4851bd03268f8f2869dd4bb33d5b6dd494af4fd470d151ffffffff010000000000000000276a06ceb34443031d1e23b030fb3be4df32e4516fa572294f7af98ff77df89ddc24becc3c53d8 ...
380 2014-05-07 15:52:55 <petertodd> ... 9500000000
381 2014-05-07 15:53:16 <dabura667> ok
382 2014-05-07 15:53:28 <petertodd> you might have had something else wrong with the tx; what tool were you using to create it?
383 2014-05-07 16:06:30 <dabura667> http://brainwallet.org/#tx
384 2014-05-07 16:06:40 <dabura667> I used this to sign my raw tx
385 2014-05-07 16:06:49 <dabura667> and it kinda f'ed it up.
386 2014-05-07 16:06:57 <petertodd> that doesn't surprise me :)
387 2014-05-07 16:07:08 <petertodd> bitcoind signrawtransaction and/or python-bitcoinlib is what I use msyelf
388 2014-05-07 16:07:45 <dabura667> http://pastebin.com/utNiAae7
389 2014-05-07 16:08:05 <dabura667> would bitcoind signrawtransaction work with this?
390 2014-05-07 16:08:13 <petertodd> no, it works with raw hex only
391 2014-05-07 16:08:23 <dabura667> ok
392 2014-05-07 16:08:34 <dabura667> so I would need to import the privkey, correct?
393 2014-05-07 16:09:20 <petertodd> frankly, if you haven't already, I *really* suggest downloading python-bitcoinlib and looking at the examples/ directory - I've got some step by step and well documented examples of how to create and sign transactions right in there
394 2014-05-07 16:10:11 <mapppum> dabura667: you can provide the WIF privkey to signrawtransaction without it being imported
395 2014-05-07 16:10:20 <petertodd> mapppum: good point!
396 2014-05-07 16:14:08 <dabura667> SUCCESS!!! haha!
397 2014-05-07 16:14:14 <petertodd> nice!
398 2014-05-07 16:14:22 <dabura667> now let's see if it actually goes to my stealth address...
399 2014-05-07 16:15:46 <dabura667> https://blockchain.info/tx/97c10ee69e5f445f99ab6edfd5531e7b21d6013ee1487f2d04559ec480e289f6
400 2014-05-07 16:16:17 <petertodd> hmm, no op_return there
401 2014-05-07 16:18:30 <dabura667> err wait
402 2014-05-07 16:18:38 <dabura667> that was the output I used haha
403 2014-05-07 16:18:46 <dabura667> https://blockchain.info/address/1E8oZd5gmfcX5a522eks1VzXfc4X3E1SEG
404 2014-05-07 16:18:54 <dabura667> This is the addy I sent from
405 2014-05-07 16:19:08 <dabura667> let's see if it shows up... blockchain rejected it.
406 2014-05-07 16:19:16 <dabura667> eligius accepted it!
407 2014-05-07 16:21:02 <dabura667> 2ae22a393045a34ab634788117422607f092d061d39549c9b3e96259a5be0361
408 2014-05-07 16:21:07 <dabura667> this is the tx hash
409 2014-05-07 16:40:13 <dabura667> went through, but not showing up in DW uh ohhhhh lol
410 2014-05-07 16:40:25 <dabura667> looks like I failed somewhere
411 2014-05-07 17:02:06 <kdomanski> in function "Value listlockunspent(const Array& params, bool fHelp)" a certain 'unsigned int' is being cast to 'int' before being pushed_back to an Object
412 2014-05-07 17:02:15 <kdomanski> is there a reason for that?
413 2014-05-07 17:09:41 <Guest4402> Hello. Would it be disruptive to submit the same exact transaction (using sendrawtransaction) from multiple wallets at about the same time? Thanks.
414 2014-05-07 17:10:47 <gwillen> Guest4402: No, that should be fine.
415 2014-05-07 17:10:54 <gwillen> Guest4402: at worst it will have no effect.
416 2014-05-07 17:11:15 <gwillen> Guest4402: at best it will speed up propagation somehwat.
417 2014-05-07 17:11:24 <Guest4402> I want the various parties in the transaction to know that it got submitted.
418 2014-05-07 17:12:13 <gwillen> Guest4402: Yeah, that's totally a fine thing to do, then. They should be aware that being submitted doesn't guarantee anything. (And typically if they're connected to the network, they'll know within moments that it was submitted, because they will get it from the network.)
419 2014-05-07 17:12:30 <Guest4402> right
420 2014-05-07 17:12:54 <Guest4402> gwillen: thanks
421 2014-05-07 17:13:20 <gwillen> Guest4402: np
422 2014-05-07 17:27:09 <ajweiss> can libbitcoin be run as a full node today?
423 2014-05-07 17:28:53 <ajweiss> they have an example wrapper program that looks like it might work, but not much documentation...
424 2014-05-07 17:30:58 <hearn> i think itâs the backend to dark wallet
425 2014-05-07 17:31:06 <hearn> so presumably â¦. not sure how much of the protocol it implements though
426 2014-05-07 17:31:18 <hearn> i noticed a suspicious lack of filed issues when i last looked at their github. i am curious how many users it has.
427 2014-05-07 17:36:59 <hearn> wumpus: why not split the 0.9.2 branch now? it looks bad to have pulls hanging around for months and branch management does not require it
428 2014-05-07 17:39:37 <Guest4402> what happens to wallet keypairs after a keypair has been spent? would there be a way to purge the keypair from the wallet? I'm asking because a wallet owner may not want to have evidence of previous spending on his computer...
429 2014-05-07 17:40:21 <hearn> itâs not supported. if someone did try to send you money again, it would be permanently destroye
430 2014-05-07 17:40:33 <Guest4402> understood
431 2014-05-07 17:41:04 <hearn> you can always encrypt the wallet (with pgp or truecrypt) if you want to hide it, or if even that is too much, export the private key/hd seed and stego it into an image of your kids or whatever
432 2014-05-07 17:41:21 <Guest4402> so emptying the wallet and creating a new wallet would be the only way?
433 2014-05-07 17:41:37 <hearn> indeed, built-in image stego might be a neat way to hide wallets. though itâd need thought.
434 2014-05-07 17:41:45 <hearn> well it depends what wallet app you use
435 2014-05-07 17:42:01 <petertodd> dabura667: ah, you're code is very messed up - it's not even encoding pushdata's correctly. secondly stealth uses one pushdata, not two.
436 2014-05-07 17:42:19 <Guest4402> thing of ladar and lavabit. the government can compel a person to do anything it wants
437 2014-05-07 17:42:22 <Guest4402> thinking
438 2014-05-07 17:42:41 <petertodd> dabura667: the working specification is here BTW: https://wiki.unsystem.net/index.php/DarkWallet/Stealth
439 2014-05-07 17:44:10 <hearn> Guest33406: *if* they know you have the wallet then youâre out of luck
440 2014-05-07 17:44:38 <hearn> Guest33406: if they donât know that, or merely suspect it, hiding the wallet could be effective. though tricky - if you have zero wallets on your computer, but a wallet app that supports hiding wallets â¦â¦ well, 2+2 = ?
441 2014-05-07 17:45:08 <hearn> also thereâs a very simple workaround for the adversary. seize the whole computer and stop you getting to another one.
442 2014-05-07 17:45:44 <Guest4402> yes, and that is sometimes a condition od bail/probation/parole
443 2014-05-07 17:46:07 <Guest4402> but this is the dev forum...
444 2014-05-07 17:46:10 <hearn> right. though lavabit isnât a great example btw. levison picked a fight.
445 2014-05-07 17:46:21 <hearn> better examples would be the american practice of civil forfeiture
446 2014-05-07 17:46:37 <Guest4402> you're a Brit?
447 2014-05-07 17:47:03 <hearn> yes. why?
448 2014-05-07 17:48:53 <Guest4402> hearn: lived in London for two years, enjoyed the experience. I'm always comparing the two justice systems.
449 2014-05-07 17:49:32 <ajweiss> hearn: are there other implementations that are closer to becoming full nodes? the bitcoinj stuff is headed that way, yeah?
450 2014-05-07 17:49:36 <hearn> i donât think the UK has any equivalent to civil forfeiture. plenty of other bad laws though
451 2014-05-07 17:49:52 <hearn> ajweiss: no. bitcoinj has a fully validating mode but it doesnât relay and isnât usable for mining.
452 2014-05-07 17:49:59 <hearn> ajweiss: why do you want a different full node?
453 2014-05-07 17:50:22 <ajweiss> personally, i don't. i am interested to see how this is going to play out though...
454 2014-05-07 17:51:25 <ajweiss> the idea of multiple implementations, at least during the teeth cutting phase is pretty terrifying if you ask me... but there are no signs to say that it won't happen...
455 2014-05-07 17:52:52 <dabura667> petertodd: you're talking about this, correct? http://pastebin.com/0MwL1WmY
456 2014-05-07 17:54:16 <petertodd> dabura667: yeah, if you run that through bitcoind decoderawtransaction you'll see the op-return script is outright invalid
457 2014-05-07 17:54:45 <petertodd> dabura667: what tools are you using?
458 2014-05-07 17:55:02 <dabura667> I just wrote the bytes directly.
459 2014-05-07 17:55:31 <hearn> ajweiss: well, one reason youâre having trouble finding some is that most people donât do it :) there is one called btcd though that i see in my getpeers sometimes
460 2014-05-07 17:55:33 <petertodd> dabura667: ah, yeah, that's rather hard to do :)
461 2014-05-07 17:55:40 <dabura667> I guess
462 2014-05-07 17:55:40 <hearn> ajweiss: and thereâs a ruby based one coinbase uses (bad idea)
463 2014-05-07 17:56:11 <ajweiss> oh weird btcd is in go
464 2014-05-07 17:56:20 <petertodd> dabura667: remember that when you write a script to do this stuff, you only need to get it right once...
465 2014-05-07 17:56:58 <dabura667> literally, it's just 6a (OP_RETURN) 06 <4byte nonce> <33byte pubkey> all written like s += '6a' etc
466 2014-05-07 17:57:16 <hearn> ajweiss: yeah itâs written by a company that love Go for some reason
467 2014-05-07 17:57:18 <hearn> ACTION does not love Go
468 2014-05-07 17:57:38 <petertodd> dabura667: nope - you need a pushdata opcode in there
469 2014-05-07 17:58:24 <dabura667> -> RETURN <version:1=6> <nonce:4> <P:33>
470 2014-05-07 17:58:50 <petertodd> dabura667: that was written with the implicit understanding that all that data would be packaged up in a pushdata operation
471 2014-05-07 17:58:51 <dabura667> I guess it was common knowledge? This is my first time messing with script.
472 2014-05-07 17:58:58 <petertodd> dabura667: yup, common knowledge
473 2014-05-07 17:59:03 <dabura667> doh
474 2014-05-07 17:59:10 <coryfields> wumpus: I've got 64bit 10.6min osx bitcoin-qt building on linux. probably another day or so to cleanup. Should be no problem for 0.9.2.
475 2014-05-07 17:59:48 <petertodd> dabura667: also, you need to do ecdh and ECC key derivation too to get it all correct
476 2014-05-07 18:00:08 <dabura667> Electrum adds bits like so http://pastebin.com/PBMBG6e9
477 2014-05-07 18:00:14 <dabura667> this is my altered code
478 2014-05-07 18:00:58 <dabura667> I got the ECC stuff down ok, I checked against your test cases and the sx python libraries
479 2014-05-07 18:01:29 <petertodd> dabura667: ah cool. by "my" test cases you mean my address format test cases right? I don't have ECC test cases yet
480 2014-05-07 18:01:59 <dabura667> yeah your address format stuff and the sx python libraries
481 2014-05-07 18:02:22 <dabura667> so what kind of bytes would I need to add before OP_RETURN?
482 2014-05-07 18:02:58 <ajweiss> hearn: they rolled their own ruby based fullnode?
483 2014-05-07 18:03:14 <hearn> i think so. or at least, tried â¦. it has a history of getting forked off the chain.
484 2014-05-07 18:03:20 <hearn> iâm not sure how compliant it is
485 2014-05-07 18:03:28 <petertodd> dabura667: see https://en.bitcoin.it/wiki/Script#Constants
486 2014-05-07 18:05:40 <dabura667> ok
487 2014-05-07 18:05:45 <petertodd> dabura667: and you know, if you're interested, I'd certainly appreciate some transaction generation code for my stealth addresses reference implementation: https://github.com/petertodd/stealth-addresses-ref-implementation
488 2014-05-07 18:06:01 <petertodd> dabura667: might be an easier way for you to learn it rather than working on electrum as step #1
489 2014-05-07 18:06:10 <dabura667> true
490 2014-05-07 18:06:27 <dabura667> electrum is kinda messy to step around
491 2014-05-07 18:06:46 <dabura667> so let me see if my understanding is correct.
492 2014-05-07 18:07:39 <dabura667> So anything that is not an OPcode must have one of the constants less than or equal to 0x4e (OP_PUSHDATA4)
493 2014-05-07 18:07:56 <dabura667> so if I want to push more than 75 bytes on the stack
494 2014-05-07 18:08:15 <dabura667> I need a PUSHDATA1 + the byte over 75
495 2014-05-07 18:08:18 <petertodd> dabura667: yup
496 2014-05-07 18:08:27 <dabura667> ok sounds good.
497 2014-05-07 18:08:29 <dabura667> thanks a lot
498 2014-05-07 18:09:51 <petertodd> so in python-bitcoinlib, you can see this with b2x(CScript([b'\x00'*n])) <- basically makes a script with a pushdata of n bytes, and b2x just turns the CScript() object, a bytes subclass, into hex for you
499 2014-05-07 18:12:25 <dabura667> ok I'll try wedging in 0x26 (38) between OP_RETURN and the version byte.
500 2014-05-07 18:43:18 <dabura667> petertodd: should I be doing the PUSHDATA for each separate thing? ie. pushdata <version1byte> PUSHDATA <nonce4bytes> PUSHDATA <P:33bytes> ?
501 2014-05-07 18:44:16 <sipa> you don't need pushdata for pushes up to 76 bytes
502 2014-05-07 18:50:32 <dabura667> yes, sorry that's what I meant
503 2014-05-07 18:53:52 <dabura667> I checked some of the stealth txes from testnet I made.
504 2014-05-07 19:14:05 <michagogo> cloud|sipa: opcodes 1-76 are pushdata by definition, are they not?
505 2014-05-07 19:14:49 <michagogo> cloud|It's pushdata1 that you don't need for up to 76 bytes
506 2014-05-07 19:16:02 <sipa> oh, are they called that way? ok
507 2014-05-07 19:16:19 <sipa> opcode 0 too, btw
508 2014-05-07 19:20:27 <michagogo> cloud|sipa: I think they are⦠may depend on what you're looking at
509 2014-05-07 19:21:01 <michagogo> cloud|Also, it's weird that (as far as I could tell) there isn't a single opcode to push a zero byte onto the stack
510 2014-05-07 19:21:18 <sipa> that is correct
511 2014-05-07 19:21:20 <Luke-Jr> michagogo|cloud: why?
512 2014-05-07 19:21:33 <sipa> but the number 0 is the empty vector
513 2014-05-07 19:21:34 <michagogo> cloud|There are single-opcode pushes for 1-16, but to push zero requires 0100
514 2014-05-07 19:21:54 <Luke-Jr> michagogo|cloud: no, OP_FALSE pushes the number zero
515 2014-05-07 19:22:02 <michagogo> cloud|Oh?
516 2014-05-07 19:22:06 <Luke-Jr> as sipa said
517 2014-05-07 19:22:15 <michagogo> cloud|;;bc,wiki script
518 2014-05-07 19:22:16 <gribble> https://en.bitcoin.it/wiki/Script | Mar 11, 2014 ... Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack- based, and processed from left to right. It is purposefully not ...
519 2014-05-07 19:22:18 <sipa> yes, because the numbers 1-16 are represented by a single byte vector
520 2014-05-07 19:22:32 <sipa> the number 0 is represened by an empty vector
521 2014-05-07 19:22:45 <sipa> so that is what op_0 pushes
522 2014-05-07 19:24:25 <michagogo> cloud|Oh, really?
523 2014-05-07 19:24:50 <michagogo> cloud|So what does 0100 get you?
524 2014-05-07 19:24:50 <sipa> yes
525 2014-05-07 19:25:02 <sipa> it pushes the single-byte vector 0x00
526 2014-05-07 19:25:23 <michagogo> cloud|And why is OP_0 not contiguous with OP_1-16?
527 2014-05-07 19:25:33 <sipa> which is also interpreted as the number 0, but redundant
528 2014-05-07 19:25:55 <sipa> because op_0 is continupus with the other direct pushes
529 2014-05-07 19:26:19 <sipa> it just happens to push somethimg that also is the canonical representation of 0
530 2014-05-07 19:26:20 <michagogo> cloud|Oh, I get it
531 2014-05-07 19:26:38 <michagogo> cloud|It's in the category of "push the next n bytes"
532 2014-05-07 19:26:45 <sipa> bingo
533 2014-05-07 19:28:02 <michagogo> cloud|If it pushed 00, the equivalent of 0100, it would make sense as, say, 0x50
534 2014-05-07 19:28:29 <michagogo> cloud|So to create, say, a 0-of-0 multisig, you would just make it 00 00 00?
535 2014-05-07 19:29:22 <michagogo> cloud|(The use case would be to spend a transaction with a scriptPubKey of ae)
536 2014-05-07 19:29:34 <michagogo> cloud|Or an output, rather