1 2014-06-07 00:49:07 <warren> createrawtransaction won't let you use the same address in multiple outputs.
2 2014-06-07 00:49:39 <warren> Normally that's a good thing except when you want it to make a test case.
3 2014-06-07 00:50:36 <Luke-Jr> warren: create it yourself? :P
4 2014-06-07 01:00:51 <trend> sipa: I managed to start two daemons now on two diff ips, the only conflict left its rpc port
5 2014-06-07 01:01:05 <trend> maybe its something in my networking settings, go figure
6 2014-06-07 01:03:56 <Hasimir> trend, could it be nat/port forwarding?
7 2014-06-07 01:05:47 <trend> or the fact its adds all ips via add local? I just read debug
8 2014-06-07 01:06:08 <trend> oki best use separate box then
9 2014-06-07 01:08:03 <warren> Luke-Jr: any recommended tools?
10 2014-06-07 01:27:57 <Luke-Jr> warren: it's not like transaction format is complex.. I just use a text editor :P
11 2014-06-07 01:28:59 <phantomcircuit> warren, build a transaction using two different addresses
12 2014-06-07 01:29:06 <phantomcircuit> then copy the hash from one to the other
13 2014-06-07 01:29:22 <phantomcircuit> (verify tx is valid before broadcasting of course)
14 2014-06-07 01:41:54 <petertodd> warren: python-bitcoinlib <- my answer to life, the universe, and everything
15 2014-06-07 01:43:41 <poutine> I use bitcoinjs lib
16 2014-06-07 01:43:56 <petertodd> there is more than one answere
17 2014-06-07 01:46:29 <phantomcircuit> petertodd, if its the answer to everything
18 2014-06-07 01:46:35 <phantomcircuit> then how can there be more than one
19 2014-06-07 01:47:15 <petertodd> phantomcircuit: "my answere", not "the answere" :)
20 2014-06-07 01:47:44 <petertodd> and actually, reminds me, I gotta look at the networking patches someone sent me for it...
21 2014-06-07 01:47:48 <phantomcircuit> lol
22 2014-06-07 01:50:10 <dabura667> https://blockchain.info/tx/58b3bfb7e2a9be2c0bb684b47730b7e78c3743a57f1e590fc12577a61acdc0a4?format=hex
23 2014-06-07 01:50:41 <dabura667> Can anyone tell me what the fdfe00 means for the scriptLen
24 2014-06-07 01:51:10 <dabura667> I counted bytes and scriptlen should be 254 bytes... so fe... but what are the fd and 00 surrounding it...
25 2014-06-07 01:51:20 <dabura667> (for the input)
26 2014-06-07 01:51:53 <dabura667> I am trying to wrap my head around it. Thanks in advanced
27 2014-06-07 01:52:31 <petertodd> dabura667: look at varints on the bitcoin wiki
28 2014-06-07 01:53:55 <dabura667> https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
29 2014-06-07 01:53:58 <dabura667> found it, thanks
30 2014-06-07 01:58:28 <dabura667> ok, so because the value fe was not less than fd but was lessthan or equal to ffff, it takes 3 bytes, fd to denote uint16_t and then little endian integer fe00 (254). Awesome stuff, problem solved. Thank you.
31 2014-06-07 01:59:29 <petertodd> np
32 2014-06-07 02:10:42 <dabura667> petertodd: Also, I saw the PR for replace by fee. Seems very interesting. I had heard Elgius implemented Child pays for parent, so I had been spending unconfirmed outputs that are in limbo for too long by respending with a big fee and pushing to elgius.
33 2014-06-07 02:11:22 <dabura667> If your PR gets in and it gets used a lot, I should be able to just resend the same output with a proper fee, correct?
34 2014-06-07 02:12:05 <petertodd> dabura667: absolutely, and if you sign with SIGHASH_ANYONECANPAY, anyone can add inputs to the transaction to get it mined themselves
35 2014-06-07 02:13:14 <dabura667> I didn't quite get that part... what's the use case if you don't mind me asking?
36 2014-06-07 02:15:12 <petertodd> basically SIGHASH_ANYONECANPAY just says "this output can be spent in a transaction with these outputs, and I don't care who else pays into the transaction" - normally all inputs are signed as well so you can't add additional inputs
37 2014-06-07 02:15:27 <poutine> kickstarter-like program dabura667?
38 2014-06-07 02:17:09 <petertodd> poutine: it's a kickstarter in every transaction!
39 2014-06-07 02:18:17 <dabura667> hmmm... How would the amount of the outputs be changed? Each change to the output amount would invalidate the sigs of the previous input signers, or do you remove the amount from the outputs for signing?
40 2014-06-07 02:18:48 <poutine> dabura667, with kickstarter you have a goal, you can have a tx output amount, right?
41 2014-06-07 02:19:22 <petertodd> dabura667: the output amounts isn't changed, how many inputs there are is
42 2014-06-07 02:19:34 <dabura667> ahhh ic...... I'd hate to be the last guy to tip it up to the output amount and use a 50 BTC input lol
43 2014-06-07 02:19:49 <dabura667> 49 BTC miners fee?
44 2014-06-07 02:19:52 <dabura667> etc.
45 2014-06-07 02:20:00 <poutine> the miner would love it though (that is, if the tx wouldn't be rejected for the crazy fee, which it would in current bitcoind)
46 2014-06-07 02:20:23 <petertodd> dabura667: indeed, public anyonecanpay kickstarters can be really dangerous
47 2014-06-07 02:20:42 <petertodd> poutine: that's only in the RPC, the mempool will accept anything
48 2014-06-07 02:21:19 <dabura667> you'd have to calculate inputs to be exactly the output... would be a tricky thing to code for... "We're sorry, your input is too large to donate to the kickstarter, please try again"
49 2014-06-07 02:21:59 <petertodd> dabura667: well, you can repeat the transaction with funds from the previous valid tx
50 2014-06-07 02:22:02 <dabura667> "0.00000001 BTC until goal... please donate 1 satoshi output only." lol (I'm sure there'd be ways around it)
51 2014-06-07 02:22:30 <dabura667> hmmm
52 2014-06-07 02:22:31 <poutine> You could discard more dust-like transactions
53 2014-06-07 02:22:46 <poutine> to accommodate the large one
54 2014-06-07 02:23:25 <poutine> dust-like inputs I should say
55 2014-06-07 02:27:09 <dabura667> What's that one game where you get to pick a certain number of things between 1 and 3, and you go back and forth between your opponent and you try to make them pick the last one...
56 2014-06-07 02:27:31 <dabura667> it made me think of that game.
57 2014-06-07 02:27:45 <poutine> bar hopping with a wing man?
58 2014-06-07 02:28:55 <dabura667> So to change topic: I am working with the Cryptocurrency Tech Japan group to start a discussion meeting on privacy at the protocol level for Bitcoin.
59 2014-06-07 02:30:46 <petertodd> dabura667: interesting
60 2014-06-07 02:31:17 <dabura667> I would be very interested to hear anyone/everyone's opinion on privacy and how we should deal with it in regards to the Bitcoin protocol before it ossifies due to embeded hardware like trezor and whatever comes after it.
61 2014-06-07 02:31:59 <dabura667> I think TCP/IP should have implemented a TOR type function at protocol base before going mainstream... then the NSA wouldn't spy on my stuff even though I am not in the USA
62 2014-06-07 02:32:00 <petertodd> dabura667: well, the likes of trezor aren't necessarily incompatible with things like coinjoin
63 2014-06-07 02:32:06 <dabura667> true
64 2014-06-07 02:33:08 <dabura667> what I mean, is that as things are made more and more hardware based and large manufacturing businesses depend on their hardware to work with a certain protocol, privacy on a protocol level will become more difficult.
65 2014-06-07 02:33:32 <dabura667> just like tor is an after thought to TCP/IP
66 2014-06-07 02:34:13 <dabura667> stealth addresses and coinjoin may just be a niche case, and the NSA will have big data processors checking everyone's payment habits for advertisement companies.
67 2014-06-07 02:34:35 <jcorgan> this really isn't -dev related
68 2014-06-07 02:35:14 <petertodd> dabura667: well the question is how flexible will that hardware be, and how widespread are these technologies prior to wide deployment of that hardware?
69 2014-06-07 02:36:38 <dabura667> jcorgan: privacy doesn't just code itself. The discussion I want to lead the conversation into is "including what is currently available, coinjoin, stealth etc. what other things could we do to the protocol to guarantee privacy?" so I would say -dev related...
70 2014-06-07 02:37:36 <Hasimir> dabura667, what, you mean ipsec? plans are for IPv6 to have it enabled by default (essentially everything is encrypted)
71 2014-06-07 02:37:37 <petertodd> dabura667: an important one is to encrypt node to node connections, most importantly SPV client to node connections
72 2014-06-07 02:37:47 <jcorgan> sorry, i kinda jumped in the middle and didn't read the scrollback, no worries
73 2014-06-07 02:37:47 <petertodd> Hasimir: that's incorrect
74 2014-06-07 02:38:03 <Hasimir> I knew it was too good to be true
75 2014-06-07 02:40:44 <dabura667> petertodd: That's the thing I am interested in... I think that for Bitcoin to go mainstream there are two methods: 1. Centralized things like Circle (this will be MUST for mid-early mass adoption) 2. Embeded hardware using transferable seeds/keys. (meaning my phone and notebook both come with embeded chips that bypass the OS to do tx creation and signing. Then with a thumb print or something, I could transfer my seed or keys f
76 2014-06-07 02:40:44 <dabura667> rom one chip to another without going through the OS... etc. This will be when people are more comfortable with bitcoin. Then of course there will be software pre-installed on android / iphone / windows to interface with those chips without the customer knowing about BIP32 etc.
77 2014-06-07 02:41:36 <dabura667> I am talking about those chips.
78 2014-06-07 02:42:38 <dabura667> as trezor basically just signs txes, you can use it flexible ways, but if someday in the sake of user friendliness we put all the basic functions of bitcoin on a chip... those functions will be harder and harder to change.
79 2014-06-07 02:43:02 <petertodd> I can assure you that "chip" will be a reprogrammable microprocessor :)
80 2014-06-07 02:43:12 <dabura667> hopefully :-0
81 2014-06-07 02:43:21 <petertodd> quite likely with firmware that can be reprogrammed over usb... without authentication :(
82 2014-06-07 02:43:56 <poutine> how does the trezor prevent txout modification in software?
83 2014-06-07 02:44:02 <poutine> pre-sign
84 2014-06-07 02:44:09 <petertodd> poutine: it doesn't
85 2014-06-07 02:44:28 <petertodd> poutine: that's the main driver behind the need for a payment protocol actually
86 2014-06-07 02:45:36 <dabura667> e time.
87 2014-06-07 02:45:36 <dabura667> true... but firmware update rates on home pc hardware for the average joe is abysmal... maybe if the future has 100% always on internet for everyone, and forces background update of firmware for hardware... then I could see hard-fork level changes being possible... but my mom's router is on like 5 year old firmware, and the manufacturer said on their site her firmware had a major bug etc... I laughed, but not really at the sam
88 2014-06-07 02:45:51 <dabura667> Yeah BIP70 is great
89 2014-06-07 02:46:06 <petertodd> automatic updates of anything can be severe security holes...
90 2014-06-07 02:46:45 <petertodd> payment protocols are great, BIP70... well at least it'll give us yet more evidence that the CA system isn't very good
91 2014-06-07 02:47:03 <poutine> Well I guess whatever software they force you to use would show you the output, or verify it, but all of these things could happen with a piece of malware if the value in it were significant enough
92 2014-06-07 02:47:14 <petertodd> poutine: exactly
93 2014-06-07 02:47:33 <dabura667> exactly... that brings us back to my point of hardware dictating what can and can't be changed in the Bitcoin protocol down the line...
94 2014-06-07 02:47:57 <dabura667> Re: petertodd
95 2014-06-07 02:48:16 <dabura667> Re: automatic updates are dangerous
96 2014-06-07 02:48:16 <petertodd> yup, but... I highly suggest you go out and write code that implements privacy features now, rather than talk about how inconvenient it'll be to change things later ;)
97 2014-06-07 02:48:34 <dabura667> exactly, this.
98 2014-06-07 02:48:53 <dabura667> which is why I came to talk about ideas.
99 2014-06-07 02:49:10 <dabura667> took a while to get to it.
100 2014-06-07 02:49:26 <petertodd> honestly, the ideas are pretty well understood, and dark wallet is doing an excellent - albeit far too late - job implementing them
101 2014-06-07 02:50:03 <dabura667> yes, I love Dark Wallet
102 2014-06-07 02:51:04 <petertodd> yeah, that team is pragmatic enough to actually get stuff done rather than talk endlessly about what blinding protocol to use with coinjoin, gah
103 2014-06-07 02:51:15 <dabura667> but I feel like there's a movement, even amongst the bitcoin space, that companies like Circle and Coinbase want to pimp the "look NSA you can track all bitcoin users now! isn't it great!" and would hate if coinjoin was required by protocol.
104 2014-06-07 02:52:09 <petertodd> meh, you don't stop that movement by talking about it, you stop it by implementing software
105 2014-06-07 02:52:19 <dabura667> exactly
106 2014-06-07 02:52:30 <petertodd> (well, some people can stop it by talking about it... but that's because they inspire others to implement)
107 2014-06-07 02:53:19 <dabura667> what would you think of full nodes being something of an input / output collector than creates transactions.
108 2014-06-07 02:53:27 <dabura667> that*
109 2014-06-07 02:54:14 <petertodd> dabura667: not needed; read up on my ideas about two-party mixes in the original coinjoin thread - I've never been convinced it's wroth implementing anything more complex than that as your version 1.0
110 2014-06-07 02:55:04 <petertodd> and that is of course what dark wallet has implemented. still some work to do re: dos attacks, inter-wallet compatibility, etc. but it'll get there
111 2014-06-07 02:55:22 <petertodd> *worth
112 2014-06-07 02:57:55 <dabura667> hmm
113 2014-06-07 03:51:03 <hafd> hi, can I use latest wallet with db 4.6?
114 2014-06-07 04:14:35 <hafd> oki
115 2014-06-07 04:44:51 <dsnrk> is there a patch that dumps all rejected transactions to disk?
116 2014-06-07 04:52:20 <dsnrk> all of my peers claims to be Satoshi clients > 0.8 but I keep seeing invalid pubkey sizes, from "too short" to "non-canon". happening fairly fequently, so genuinely curious what someone is doing.
117 2014-06-07 04:53:36 <gmaxwell> the version string seems less than worthless, every person that makes their own client slavishly replicates it.
118 2014-06-07 04:54:18 <gmaxwell> I've toyed withâ not really seriouslyâ the idea of doing behavioral profiling and banning peers that claimed to be a particular version but didn't behave like it.
119 2014-06-07 04:54:31 <Diablo-D3> gmaxwell: that'd be interesting
120 2014-06-07 04:54:57 <dsnrk> that's incredibly annoying.
121 2014-06-07 04:55:36 <dsnrk> I want to know *why* this peer is sending me weird stuff, and why it's weird. of course whenever I load up pcap I stop seeing the rejects.
122 2014-06-07 04:56:33 <dsnrk> if it *is* a client that's lying well, how many other full nodes are there?
123 2014-06-07 04:58:04 <dsnrk> more to the point why are they sending botched public keys. I would have thought that's a fairly hard part to screw up.
124 2014-06-07 05:12:31 <jcorgan> what is the package on ubuntu 14.04 that satisfies ./configure for libdb_cxx headers?
125 2014-06-07 05:15:42 <jcorgan> nm, libdb++-dev
126 2014-06-07 06:10:48 <frt> how I can start rpc daemon on a specific ip?
127 2014-06-07 06:11:09 <frt> so far p2p port via bind hops on it but rpc port sits on 127.0.0.1
128 2014-06-07 06:11:19 <justanotheruser> frt: own that IP address?
129 2014-06-07 06:11:40 <frt> I run box with may IP address that are up
130 2014-06-07 06:11:57 <frt> I want to run daemon on specific ip both p2p and rpc ports
131 2014-06-07 06:12:14 <frt> *many
132 2014-06-07 06:14:20 <frt> justanotheruser: is it possible without hacking code? :)
133 2014-06-07 06:15:08 <justanotheruser> frt: umm...
134 2014-06-07 06:15:28 <justanotheruser> why do you need to run it from a specific IP address. Just find the IP address of the machine it's running on now
135 2014-06-07 06:16:15 <weex> doesn't this work frt?
136 2014-06-07 06:16:27 <weex> -bind=<addr> Bind to given address and always listen on it. Use [host]:port notation for IPv6
137 2014-06-07 06:16:50 <weex> oh rpc
138 2014-06-07 06:17:53 <frt> yes p2p port works, rpc jumps on 127.0.0.1 :P
139 2014-06-07 06:18:04 <dsnrk> frt: so your dual daemons load if you don't have RPC enabled?
140 2014-06-07 06:19:25 <frt> dsnrk I think reason for conflict they both want 127.0.0.1 for rpc ports
141 2014-06-07 06:19:53 <dsnrk> you can test that by just not having RPC enabled at all.
142 2014-06-07 06:20:28 <dsnrk> wait, no RPC shouldn't bind to anything but localhost
143 2014-06-07 06:21:00 <justanotheruser> dsnrk: sounds more like an LPC to me
144 2014-06-07 06:22:01 <frt> -rpcport=<port> Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332) I was thinking if its preceded by -bind it can work
145 2014-06-07 06:22:02 <frt> hehe
146 2014-06-07 06:29:14 <Luke-Jr> frt: it may be intentionally not possible
147 2014-06-07 06:32:37 <frt> Luke-Jr: ok I managed to run two of them - p2p ports 1 per IP, and 2 separate rpc ports share 127.0.01 :)
148 2014-06-07 06:32:55 <frt> and yes separate data dirs of course
149 2014-06-07 06:33:15 <dsnrk> I do still wonder why, seems like an odd thing to want to do
150 2014-06-07 06:33:26 <frt> hehe this way I can even run real net and test net on same box same time
151 2014-06-07 06:33:27 <frt> :)
152 2014-06-07 06:33:52 <dsnrk> you can do that anyway, the testnet ports are different to the mainnet ones
153 2014-06-07 06:34:04 <frt> true
154 2014-06-07 06:34:26 <frt> well I am making block explorer for many .... :) on 1 box
155 2014-06-07 06:35:05 <Luke-Jr> O.o;;;;
156 2014-06-07 06:35:14 <dsnrk> you've lost me there.
157 2014-06-07 06:42:31 <frt> btw Luke-Jr have u tried to code open source asic soft?
158 2014-06-07 06:42:45 <Luke-Jr> frt: yes, I maintain it.
159 2014-06-07 06:42:47 <frt> I saw sometime ago there was a group of people at it
160 2014-06-07 06:42:57 <frt> whats the link?
161 2014-06-07 06:43:06 <frt> if you want to share :)
162 2014-06-07 06:49:22 <frt> hehe
163 2014-06-07 06:51:52 <Luke-Jr> frt: bfgminer.com
164 2014-06-07 07:04:45 <trend> hehehe so neat!
165 2014-06-07 07:34:15 <fanquake> ;;blocks
166 2014-06-07 07:34:16 <gribble> 304613
167 2014-06-07 08:31:26 <wumpus> frt: master has -rpcbind option to be able to bind the RPC port on a specific interface, note that you also need to provide -rpcallowip to allow specific IPs if you want to bind on non-localhost
168 2014-06-07 09:27:52 <gdm85> to consider a gitian build successful, does the in_manifest have to match too? or only the out_manifest?
169 2014-06-07 09:28:07 <wumpus> gdm85: only the out_manifest
170 2014-06-07 09:28:19 <wumpus> in_manifest is just for info
171 2014-06-07 09:28:31 <gdm85> and base_manifest too, I suppose
172 2014-06-07 09:28:49 <gdm85> wumpus: ok, good. then the LC_* issue can be considered fix. I will wait for cfields to submit a PR, since he is the author of the patch anyway
173 2014-06-07 09:29:01 <gdm85> s/fix/fixed
174 2014-06-07 10:30:37 <Canuck24> Hola
175 2014-06-07 10:36:28 <acidmelt> hi, question. why are the hashes in tx's reversed? is there some good reason for that?
176 2014-06-07 10:36:35 <Canuck24> Hope I don't embarrass myself too much, but... trying to send a "version" command to a node. Should I be able to just use "telnet IP_ADDRESS 8333", connect to the node, then copy & paste the request like:
177 2014-06-07 10:36:36 <Canuck24> F9BEB4D976657273696F6E00000000006400000037C7E3CE72110100010000000000000060E8925300000000010000000000000000000000000000000000FFFFB32B9202208D010000000000000000000000000000000000FFFFD1BE7A02208D3B2EB35D8CE617650F2F5361746F7368693A302E372E322F80A90300
178 2014-06-07 10:36:49 <Canuck24> In theory, should that work? Or no?
179 2014-06-07 10:36:50 <edcba> no
180 2014-06-07 10:37:22 <edcba> you would have to paste actual bytes
181 2014-06-07 10:37:39 <edcba> ie garbage
182 2014-06-07 10:38:06 <Canuck24> So, hex -> binary format?
183 2014-06-07 10:38:10 <edcba> yes
184 2014-06-07 10:38:27 <edcba> now maybe it could but not sure whether clipboard keep nuls
185 2014-06-07 10:39:10 <edcba> learn to program already
186 2014-06-07 11:03:22 <chichov> does the reference implementation fix the pubkey script to standard transactions only or are some variations allowed?
187 2014-06-07 15:15:15 <dabura667> acidmelt: it's in little endian as compared to big endian. Google little endian and you should get an ok idea as to why.
188 2014-06-07 15:31:40 <Hasimir> how big is the testnet blockchain?
189 2014-06-07 15:34:19 <harding> Hasimir: the testnet3 directory on my computer says 1.4 GB. That includes -txindex=1 here.
190 2014-06-07 15:34:40 <Hasimir> okay, that's not too bad
191 2014-06-07 15:38:46 <Hasimir> cif someone could throw a few testbtc here, that'd be cool: mn7JrTeii2cRgUaYPTZRWbrJfG8AHRN5Jm
192 2014-06-07 15:38:53 <Hasimir> -c
193 2014-06-07 15:45:20 <cjd> Hi guys, quick question regarding the payment channels (new version post nLockTime-nonstandard)
194 2014-06-07 15:46:12 <cjd> I understand the T1 pays to a multisig and T2 is locked in the future to prevent me robbing the server but what's to prevent me bcasting T3 which pays the server like a penny after we're up to T1000
195 2014-06-07 15:47:59 <gmaxwell> the transactions are signed by both parties.
196 2014-06-07 16:01:20 <cjd> hey guys, sorry for the ask-and-run, I was just running a certain application which requires a lot of CPU power and managed to overheat my laptop
197 2014-06-07 18:00:06 <michagogo> wumpus: there?
198 2014-06-07 18:00:53 <michagogo> How come OS X Qt is getting the revision bumped with the new OpenSSL but Windows isn't?
199 2014-06-07 18:01:52 <michagogo> Also, I really think that before v0.9.2 final is tagged, release process should be changed to have the same kind of output for OS X as it does for Linux and Windows -- a versioned tarball including source.
200 2014-06-07 18:03:19 <gribble> wumpus was last seen in #bitcoin-dev 8 hours, 34 minutes, and 59 seconds ago: <wumpus> in_manifest is just for info
201 2014-06-07 18:03:19 <michagogo> ;;seen wumpus
202 2014-06-07 18:06:48 <gmaxwell> michagogo: I can't figure our what you're talking about wrt revision.
203 2014-06-07 18:06:53 <gmaxwell> er. s/our/out/
204 2014-06-07 18:07:09 <michagogo> Hm? One sec, let me check the git diff again
205 2014-06-07 18:07:16 <michagogo> Maybe I misread something
206 2014-06-07 18:08:46 <michagogo> gmaxwell:
207 2014-06-07 18:08:48 <michagogo> https://www.irccloud.com/pastebin/7sidPdEC
208 2014-06-07 18:09:41 <michagogo> and
209 2014-06-07 18:09:42 <michagogo> https://www.irccloud.com/pastebin/hchrrKSa
210 2014-06-07 18:10:33 <michagogo> gmaxwell: all 3 deps got a revision bump, as expected
211 2014-06-07 18:10:42 <michagogo> But then only OS X got a qt revision bump
212 2014-06-07 18:31:49 <michagogo> gmaxwell: do you see what I mean now?
213 2014-06-07 18:31:53 <michagogo> Or am I missing something?
214 2014-06-07 19:01:36 <wumpus> michagogo: it didn't change, so didn't need a bump
215 2014-06-07 19:01:49 <michagogo> wumpus: And OS X did?
216 2014-06-07 19:01:53 <wumpus> wumpus: if you had read the opening post of the issue, you'd know
217 2014-06-07 19:02:07 <michagogo> ACTION looks
218 2014-06-07 19:02:42 <wumpus> michagogo: and AFAIK for osx it's usual to download a bare DMG, including it in a tar/zip makes no sense
219 2014-06-07 19:02:55 <michagogo> wumpus: sure
220 2014-06-07 19:03:18 <michagogo> But look at what we do with Windows and Linux in release-process.md
221 2014-06-07 19:03:40 <wumpus> maybe the source could be included inside the dmg, it's a kind of loopback file system after all
222 2014-06-07 19:04:33 <michagogo> wumpus: following release-process, you end up with (e.g.) bitcoin-0.9.2rc1-win-gitian.zip
223 2014-06-07 19:04:45 <wumpus> which is uploaded to the site
224 2014-06-07 19:04:55 <michagogo> Hm?
225 2014-06-07 19:05:17 <wumpus> ah the part about the zip for the gitian downloader - no, that's never followed
226 2014-06-07 19:05:21 <michagogo> No, it's not
227 2014-06-07 19:05:21 <wumpus> it should really be removed
228 2014-06-07 19:05:35 <wumpus> it confused me to when I tried to do a release
229 2014-06-07 19:05:49 <michagogo> There's something lower down about repackaging that for release
230 2014-06-07 19:06:00 <wumpus> yes, as I said, that is never followed
231 2014-06-07 19:06:09 <wumpus> no repackaging happens
232 2014-06-07 19:06:36 <wumpus> as I said above, that section should be removed
233 2014-06-07 19:06:56 <michagogo> Personally, I like having those packages -- it's nice to have the output all in one place like that
234 2014-06-07 19:07:39 <michagogo> But right now, following r-p.md, the root directory ends up with bitcoin-0.9.2rc1-win-gitian.zip, bitcoin-0.9.2rc1-linux-gitian.zip, and Bitcoin-Qt.dmg
235 2014-06-07 19:08:17 <michagogo> If nothing else, I feel like the dmg name should be versioned...
236 2014-06-07 19:08:55 <michagogo> Re: https://github.com/bitcoin/bitcoin/pull/4295, what changes in the OS X qt build that doesn't change on Windows?
237 2014-06-07 19:09:06 <wumpus> adding a version number to the name sounds sensible to me
238 2014-06-07 19:09:16 <wumpus> (then again, I know nothing about mac)
239 2014-06-07 19:10:05 <wumpus> michagogo: I don't know! but I built all the dependencies, noticed that the windows one doesn't change, so didn't bump the revision, simple as that
240 2014-06-07 19:10:16 <michagogo> And the OS X one did? o_O
241 2014-06-07 19:10:26 <wumpus> michagogo: just try it out for yourself!
242 2014-06-07 19:10:53 <michagogo> ACTION tries to avoid building Qt as much as possible...
243 2014-06-07 19:12:57 <dsnrk> does anybody have a testnet IP address I can talk to? having trouble getting a new node bootstrapped.
244 2014-06-07 19:13:38 <michagogo> dsnrk: cadoth.net
245 2014-06-07 19:14:26 <michagogo> or c7nvv7pgmbitcoin.onion
246 2014-06-07 19:17:53 <torokun> How does one use cadoth? Looks like the web page is just basic info
247 2014-06-07 19:18:38 <dsnrk> michagogo: that did the trick, thank you.
248 2014-06-07 19:18:53 <michagogo> torokun: it's a server
249 2014-06-07 19:19:02 <michagogo> I happen to be running a bitcoin testnet node on there
250 2014-06-07 19:19:26 <dsnrk> is there any reason there's no working DNS seeds for testnet? I thought they worked along side the mainnet ones.
251 2014-06-07 19:21:06 <michagogo> dsnrk: I think the ML had a discussion about this at some point recently?
252 2014-06-07 19:21:43 <dsnrk> I'll go find it. the seeds work actually, just did a request manually.
253 2014-06-07 19:41:37 <dgenr8> The orphaned blocks I see completely don't match up to those seen by bc.i. I guess that's to be expected though.
254 2014-06-07 19:44:00 <dsnrk> dgenr8: their information is fairly dodgy at the best of times. are you seeing more or less?
255 2014-06-07 19:44:29 <cfields> sipa: around?
256 2014-06-07 20:25:16 <chichov> how come 5c593b7b71063a01f4128c98e36fb407b00a87454e67b39ad5f8820ebc1b2ad5 has been included in a block? aren't the spending values too small? (thus dust transaction)
257 2014-06-07 20:26:38 <chichov> could it be that there was no check for that back then?
258 2014-06-07 20:28:30 <jcorgan> chichov: dust transactions aren't relayed by the reference client, but as long as they are valid they can be mined if the miner happens to get one and so chooses
259 2014-06-07 20:29:09 <chichov> jcorgan: same goes for non-standard transaction types?
260 2014-06-07 20:29:57 <jcorgan> correct, IsStandard() controls whether they are relayed, but if they are validly formed they can be mined if you push the TX directly to a miner that does that sort of thing.
261 2014-06-07 20:30:20 <Luke-Jr> or relay it via peers with other IsStandard rules
262 2014-06-07 20:31:24 <chichov> what do you mean with "validly formed"?
263 2014-06-07 20:32:44 <chichov> and do standard nodes (reference client) accept the block afterwards if they see non-standard transactions?
264 2014-06-07 20:37:45 <Luke-Jr> chichov: "non-standard transactions", dust, and the like, are subjectively defined differently by every node
265 2014-06-07 20:37:55 <Luke-Jr> chichov: they aren't part of the bitcoin protocol, they're just policies
266 2014-06-07 20:38:17 <jcorgan> sorry, afk
267 2014-06-07 20:38:32 <chichov> Luke-Jr: but will my reference implementation not reject a freshly mined block if it has non-standard transactions?
268 2014-06-07 20:38:32 <jcorgan> what Luke-Jr said
269 2014-06-07 20:38:38 <jcorgan> no
270 2014-06-07 20:38:47 <chichov> it doesn't perform those checks?
271 2014-06-07 20:38:51 <jcorgan> "non-standard" is for relay decisions
272 2014-06-07 20:38:54 <Luke-Jr> chichov: no, if it did, then it wouldn't be Bitcoin
273 2014-06-07 20:39:14 <chichov> where can I find out what checks are done if a fresh block is received then?
274 2014-06-07 20:39:26 <Luke-Jr> AcceptBlock
275 2014-06-07 20:39:29 <jcorgan> the source code is definitive
276 2014-06-07 20:39:34 <chichov> class?
277 2014-06-07 20:39:39 <chichov> or file?
278 2014-06-07 20:39:46 <jcorgan> the wiki also has a long list, but it's probably outdated
279 2014-06-07 20:40:27 <chichov> got it, was in main.cpp:2257
280 2014-06-07 20:40:40 <chichov> luckily I have generated a doxy documentation
281 2014-06-07 20:41:27 <Luke-Jr> 1/((56.413424-56.413007)/(66*8)) <-- is this the right calculation to find baud based on two timestamps (56.*) and 66 bytes transmitted?
282 2014-06-07 20:41:47 <Luke-Jr> (I ask only because it's not what I told Linux to use..)
283 2014-06-07 20:43:02 <chichov> what about the signature, how come that the random number and the signature have to be approx. half their potential size?
284 2014-06-07 20:43:10 <chichov> order*
285 2014-06-07 20:43:21 <gwillen> Luke-Jr: assuming the two timestamps are in seconds, that looks right
286 2014-06-07 20:43:35 <Luke-Jr> ACTION ponders
287 2014-06-07 20:44:06 <Luke-Jr> ACTION wonders if mutex/logging could add that much overhead to take 4MHz down to 1.3 MHz
288 2014-06-07 20:53:10 <chichov> could someone explain why precisely the OP_0 is needed in a multisig? I know that the argumentation is that OP_CHECKMULTISIG pops too many elements off the stack, but I don't seem to see it
289 2014-06-07 21:01:23 <chichov> it only looks like a strange manouver with OP_0 to satisfy the condition in https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L892
290 2014-06-07 21:08:11 <phantomcircuit> chichov, dat bug
291 2014-06-07 21:09:20 <michagogo> Basically, due to a bug, checkmultisig takes one extra value off the stack
292 2014-06-07 21:09:33 <michagogo> And it was spotted too late to fix :-/
293 2014-06-07 21:10:20 <chichov> take a look at the link, is it exactly that part? "i" seems to be one too much
294 2014-06-07 21:10:44 <chichov> for example, for 1 signature and 3 pubkeys "i" is 7
295 2014-06-07 21:11:17 <michagogo> ;;bc,wiki checkmultisig
296 2014-06-07 21:11:18 <gribble> https://en.bitcoin.it/wiki/Contracts | May 25, 2014 ... Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the ...
297 2014-06-07 21:11:19 <chichov> then later on when the stack is popped, it tries to pop all of them
298 2014-06-07 21:11:25 <gribble> https://en.bitcoin.it/wiki/BIP_0011 | Dec 6, 2013 ... This page describes a BIP (Bitcoin Improvement Proposal). Please see BIP 0001 for more information about BIPs and creating them. Please do ...
299 2014-06-07 21:11:25 <michagogo> ;;bc,wiki op_checkmultisig
300 2014-06-07 21:11:35 <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 ...
301 2014-06-07 21:11:35 <michagogo> ;;bc,wiki script
302 2014-06-07 21:12:12 <michagogo> Ah, there it is... https://en.bitcoin.it/wiki/Script#Crypto
303 2014-06-07 21:12:20 <chichov> just saying, seems like an ugly off-by-one
304 2014-06-07 21:12:44 <michagogo> chichov: yeah, that pretty much sums it up
305 2014-06-07 21:13:01 <chichov> wanted to narrow it down in order to explain the ugly workaround
306 2014-06-07 21:13:20 <chichov> and what stops you from fixing it properly?
307 2014-06-07 21:14:12 <michagogo> chichov: me personally? I don't know c++ :P
308 2014-06-07 21:14:18 <michagogo> But it can't be fixed
309 2014-06-07 21:14:30 <michagogo> because it's already been used
310 2014-06-07 21:14:55 <michagogo> "fixing" it would be a hard fork
311 2014-06-07 21:16:22 <chichov> true, ugly
312 2014-06-07 21:16:40 <chichov> unless there is some backwards-compatible solution
313 2014-06-07 21:17:59 <michagogo> nah
314 2014-06-07 21:18:19 <michagogo> old (unfixed) software will always pull off that extra value
315 2014-06-07 21:25:09 <dgenr8> dsnrk: I looked back about 10 orphan events and none matched either way. I think it's just because one node's orphan chain is another node's main chain.
316 2014-06-07 21:26:17 <dsnrk> dgenr8: huh? all of the main chains are the exact same. the orphans might differ just due to latency.
317 2014-06-07 21:28:17 <poutine> Does anyone know of an easy way to do stack drawings illustrating script flow? I've seen some in bitcoin developer documentation, I don't know how they were generated, but I'm having to make silly drawings like http://i.imgur.com/26ijCNl.jpg when this process should be easy enough to automate
318 2014-06-07 21:31:58 <dgenr8> dsnrk: when I receive 2 new blocks, they orphan the one I had, which I previously thought was main. Another node may have received things in a different order
319 2014-06-07 21:32:39 <chichov> putine: there are some examples of script flow in my spec (http://enetium.com/resources/Bitcoin.pdf) you can check if it is the representation you're looking for
320 2014-06-07 21:33:06 <chichov> see page 19, table 4.1 and 4.2
321 2014-06-07 21:33:21 <chichov> poutine: look up
322 2014-06-07 21:34:33 <gmaxwell> poutine: I'm not aware of one, luke had started on a refactor of script.cpp that would make stepping through execution easier with the reference codebase, but it didn't get finished.
323 2014-06-07 21:34:36 <poutine> Hmm yeah I see that, I don't find it very intuitive
324 2014-06-07 21:35:19 <poutine> OK I guess I can probably do this, well at least to serve my purposes, maybe someone else will find it useful after, thanks
325 2014-06-07 21:50:03 <dsnrk> dgenr8: mm, but the view of the main chain is always the same in the end. the tip might differ sometimes but you're unlikely to see that persist for long.
326 2014-06-07 21:50:39 <dsnrk> poutine: webbtc.com does some viewing of the stack during script execution, have you seen that?
327 2014-06-07 21:50:44 <dgenr8> dsnrk: yeah, bc.i just preserves their experience for us all to see
328 2014-06-07 21:51:53 <poutine> I have dsnrk, I like their textual explanation, just was wondering about the diagramming, specifically I modeled mine after https://bitcoin.org/img/dev/en-p2pkh-stack.svg
329 2014-06-07 21:51:57 <dsnrk> dgenr8: I wouldn't rely on their website to give anything approaching reliable data, you really need to draw your own conclusions from your own observations.
330 2014-06-07 21:52:49 <dsnrk> poutine: oh right.
331 2014-06-07 21:53:43 <poutine> It seems simple enough, you just need to program in which opcodes examine which stack elements, which get popped, how to diagram weird stuff like ALTSTACK, etc, just hoped someone else did it first
332 2014-06-07 21:54:37 <dgenr8> dsnrk: absolutely. their double spend page is even worse than all their broken pages, because it actually has a tiny and apparently randomly selected bit of data.
333 2014-06-07 21:55:23 <dsnrk> dgenr8: it even fools their "head of security" https://twitter.com/mar_rak/status/472047668056047616
334 2014-06-07 21:57:40 <dgenr8> ACTION facepalms. I though AA was the head of security ... it was embarrassing when he directed his followers to malware that pretended to be some stealth address solution
335 2014-06-07 21:57:46 <chichov> what's the correct name for OP_RETURN transactions?
336 2014-06-07 21:59:16 <chichov> if there is some agreed upon terminology for that
337 2014-06-07 22:01:46 <poutine> provably prunable outputs?
338 2014-06-07 22:01:53 <dgenr8> Luke-Jr: how about block relay policy? is it still a bitcoin node if it doesn't relay blocks the way reference client would?
339 2014-06-07 22:05:31 <dsnrk> dgenr8: ref for that?
340 2014-06-07 22:06:02 <dsnrk> OH. the OSX malware.
341 2014-06-07 22:06:08 <harding> poutine: I did all the illustrations for the bitcoin.org developer guide using Graphviz. To get the source files for any of the images just s/svg$/dot/ the URL. If you need more help, feel free to PM me.
342 2014-06-07 22:06:13 <dsnrk> yeah nice job on that on genius.
343 2014-06-07 22:19:42 <warren> mmmm
344 2014-06-07 22:19:46 <warren> 149d1cd65b8b446c1e008cf54989e2110bc5601e9e9d1d02fc9e0564a3ac40e8 qt-linux64-4.6.4-gitian-r1.tar.gz
345 2014-06-07 22:19:46 <warren> c21c2bc08c100cef150b54551ac67f3484b607d80fc41288b0d0b8f2f54042a7 qt-linux32-4.6.4-gitian-r1.tar.gz
346 2014-06-07 22:19:51 <warren> neither of these match
347 2014-06-07 22:20:13 <warren> these are clean images