1 2013-09-30 06:29:52 <TBZ1> I come across programming/script bounties about once a day on bitcointalk. if anyone wants links compiled now or later, please PM me
  2 2013-09-30 10:09:03 <swulf--> i'm working on getting bitcoin built using msvc 2010
  3 2013-09-30 10:09:11 <swulf--> seems to be going ok so far
  4 2013-09-30 10:14:17 <swulf--> bitcoind had a few runtime exceptions in the msvc stl
  5 2013-09-30 10:18:26 <swulf--> can anyone spare some testnet coins?
  6 2013-09-30 11:18:16 <t7> testnet faucet ?
  7 2013-09-30 11:31:49 <yrashk> swulf--: tpfaucet.appspot.com
  8 2013-09-30 12:56:49 <TD> sipa: is the "s < order/2" rule going to be enforced at some point? i assume this is the case for the anti-malleability work
  9 2013-09-30 12:57:58 <sipa> TD: i was planning on writing a BIP about it at some point, together with some other rules to kill mallebaility, and see how people like it
 10 2013-09-30 12:58:04 <TD> please do
 11 2013-09-30 12:58:06 <sipa> so if it were up to me, yes
 12 2013-09-30 12:58:15 <TD> i can implement the same rule in bitcoinj
 13 2013-09-30 12:59:52 <sipa> another rule would be what is implemented in #3025
 14 2013-09-30 13:00:51 <sipa> but the last one is probably the hardest one: sigscripts must be push-only, and when evaluating a scriptpubkey, only a single non-zero value may remain on the stack
 15 2013-09-30 13:01:27 <sipa> maybe there are even scripts in use already that fail this
 16 2013-09-30 13:01:28 <TD> well, it's maybe a suitable fix for tx versions 1
 17 2013-09-30 13:01:51 <TD> for a hard fork, v2 could contain the number of elements in each scriptSig field as part of the CTxIn structure, covered by the sighash
 18 2013-09-30 13:13:25 <CodeShark> IMHO the signatures should be stored in a separate structure from the input script
 19 2013-09-30 13:14:19 <CodeShark> and the signing operations should probably be treated separately from the other logical operations in the script
 20 2013-09-30 13:15:40 <CodeShark> OP_CHECKSIG is at a completely different level of abstraction than say, OP_EQUAL
 21 2013-09-30 13:15:51 <swulf--> code: i'd like to see something like that, too..
 22 2013-09-30 13:16:16 <swulf--> codeshark: basically, separating 'who can pay' versus 'how/whether or not (those) can pay?'
 23 2013-09-30 13:16:18 <swulf--> ?
 24 2013-09-30 13:16:24 <swulf--> s/pay/spend
 25 2013-09-30 13:17:34 <CodeShark> swulf: yeah, sorta I guess
 26 2013-09-30 13:18:50 <CodeShark> also, I find it extremely annoying that bitcoin addresses correspond to a particular format of a hash of a public key for a particular type of script
 27 2013-09-30 13:19:00 <CodeShark> addresses should correspond to output scripts
 28 2013-09-30 13:19:12 <CodeShark> for full generality
 29 2013-09-30 13:20:17 <swulf--> right, for full generality it's very hard to tell who the intended recipient of the coins are supposed to be
 30 2013-09-30 13:21:22 <CodeShark> swulf: indeed - right now implementations resort to hideous hackery, basically having a separate case for each type of transaction
 31 2013-09-30 13:21:30 <swulf--> yup
 32 2013-09-30 13:21:35 <swulf--> that's how i've had to unfortunately code up mine
 33 2013-09-30 13:22:00 <CodeShark> at the cost of four extra bytes per address, we could represent a pay-to-bitcoin-address output in its entirety
 34 2013-09-30 13:22:16 <CodeShark> and we could even get rid of the "version" number and get one back
 35 2013-09-30 13:22:31 <CodeShark> so three more bytes than now
 36 2013-09-30 13:22:57 <CodeShark> and "pay-to-script-hash" outputs are a tiny bit shorter :)
 37 2013-09-30 13:23:41 <swulf--> I'm afk for a few:)
 38 2013-09-30 13:24:03 <sipa> CodeShark: or if we switch to p2sh-only, things become even easier
 39 2013-09-30 13:24:09 <sipa> 20 bytes for any address
 40 2013-09-30 13:24:29 <CodeShark> sipa: yeah, I guess that would provide full generality
 41 2013-09-30 13:24:34 <sipa> and wallets need hackery anyway
 42 2013-09-30 13:24:39 <sipa> but that is not a problem
 43 2013-09-30 13:24:47 <sipa> as they generate their own addresses
 44 2013-09-30 13:24:52 <sipa> so they know what they need to support
 45 2013-09-30 13:25:42 <CodeShark> right - but since the payment protocol deals with output scripts, not addresses, I think addresses will eventually die (at least I hope so)
 46 2013-09-30 13:26:55 <sipa> i hope so, but i doubt it
 47 2013-09-30 13:27:51 <CodeShark> it's weird that someone would come up with this fairly general scripting language only to label special cases of outputs by special datatypes they contain
 48 2013-09-30 13:29:05 <CodeShark> I mean, I could understand if it afforded substantial compression ratios
 49 2013-09-30 13:29:08 <sipa> pay-to-pubkeyhash addresses were only added later, to deal with the special case where you couldn't reach the receiver directly (pay-to-IP, which negotiated the script on the fly), but you did have a hash of a key :)
 50 2013-09-30 13:29:23 <sipa> they weren't intended to become the only way at all
 51 2013-09-30 13:29:51 <CodeShark> sipa: even then, we're talking removing four out of 24 bytes at the cost of full generality
 52 2013-09-30 13:30:32 <CodeShark> and this is only for the UI
 53 2013-09-30 13:30:37 <CodeShark> it has no effect on the block chain itself
 54 2013-09-30 13:31:18 <CodeShark> actually, right now it's for the UI - in the future it will be handled by a protocol layer that sits below the UI
 55 2013-09-30 13:32:47 <CodeShark> so we're talking another what…two base58 characters at most?
 56 2013-09-30 13:33:03 <CodeShark> three
 57 2013-09-30 13:33:19 <sipa> meh, humans shouldn't see addresses anyway :)
 58 2013-09-30 13:33:40 <edcba> ??
 59 2013-09-30 13:34:00 <CodeShark> right, but given the primitive nature of the first bitcoin client UIs, they needed a representation for a redeemable script
 60 2013-09-30 13:34:13 <edcba> how do you give a return address to a website ?
 61 2013-09-30 13:34:27 <sipa> edcba: the protocol your client talks with the receiver should deal with that
 62 2013-09-30 13:34:58 <edcba> http ?
 63 2013-09-30 13:35:11 <sipa> whatever protocol
 64 2013-09-30 13:35:30 <sipa> (the payment protocol being developed uses https)
 65 2013-09-30 13:35:32 <CodeShark> http is really a transport layer here :)
 66 2013-09-30 13:35:49 <edcba> maybe i missed a part of conversation
 67 2013-09-30 13:36:15 <sipa> edcba: you know what the payment protocol does?
 68 2013-09-30 13:42:47 <CodeShark> 6 more base58 chars to represent a full pay-to-pubkey-hash output. It's a few, but I don't think it would matter - as if the current addresses are particularly easy to memorize :p
 69 2013-09-30 13:43:37 <CodeShark> 5 more if we get rid of the version byte
 70 2013-09-30 13:44:53 <CodeShark> we could also use only a portion of the MD160 for "minihashes" - especially for smaller transactions
 71 2013-09-30 13:45:46 <CodeShark> the number of bytes used from the hash - or the hash function - could be parametrized into a human-readable representation
 72 2013-09-30 13:47:07 <CodeShark> and if we separated the signatures from the script altogether and replaced OP_CHECKSIG we get rid of another byte :)
 73 2013-09-30 13:49:13 <CodeShark> also, I propose getting rid of the terms "scriptsig" and scriptpubkey" since they are only strictly accurate for pay-to-pubkey transactions
 74 2013-09-30 13:49:29 <CodeShark> txinscript and txoutscript or simply input script and output script are better :)
 75 2013-09-30 13:50:50 <CodeShark> or if we want a more semantic rather than syntactic naming, something like claim script and payment script
 76 2013-09-30 13:51:15 <sipa> they are the bitcoin-pubkey and bitcoin-signature :)
 77 2013-09-30 13:51:35 <sipa> you can see bitcoin's scripting system as an (advanced) public key system on top of ECDSA
 78 2013-09-30 13:51:46 <sipa> though i assume the terminology is actually historical
 79 2013-09-30 13:54:01 <CodeShark> for standard pay-to-pubkey transactions, the two correspond exactly (except for the ugly, unnecessary OP_CHECKSIG)
 80 2013-09-30 13:55:39 <CodeShark> for most of today's transactions, both the signatures AND the public keys are stored in inputs
 81 2013-09-30 13:56:03 <CodeShark> and the outputs contain hashes
 82 2013-09-30 13:57:12 <CodeShark> and yes, it could be thought of as a "higher level pubkey system" - but these original terms are apt to cause confusion
 83 2013-09-30 13:59:22 <CodeShark> fwiw I'm no longer using them internally for variable naming :)
 84 2013-09-30 13:59:31 <CodeShark> or have been moving away from doing so
 85 2013-09-30 14:06:22 <lmatteis> hell
 86 2013-09-30 14:06:25 <lmatteis> *hello
 87 2013-09-30 14:06:35 <lmatteis> what's a good book for understanding how bitcoin works under the hoods
 88 2013-09-30 14:06:38 <lmatteis> (i'm a developer)
 89 2013-09-30 14:06:45 <lmatteis> about the block chain and all those concepts
 90 2013-09-30 14:09:00 <CodeShark> I can recommend two sources as must-reads for any developer looking to get under the hood: http://bitcoin.org/bitcoin.pdf and https://en.bitcoin.it/wiki/Protocol_specification
 91 2013-09-30 14:09:54 <CodeShark> and the third source would be the source code of an implementation
 92 2013-09-30 14:10:07 <CodeShark> so https://github.com/bitcoin/bitcoin
 93 2013-09-30 15:06:28 <lmatteis> CodeShark: thanks
 94 2013-09-30 15:07:24 <Neozonz> disc|what is the max number of maxconnections the client can be set to?
 95 2013-09-30 15:14:50 <sipa> Neozonz|disc: 1000 or so
 96 2013-09-30 15:15:00 <sipa> depends on the OS, though
 97 2013-09-30 15:16:56 <Neozonz> disc|ah ok
 98 2013-09-30 15:17:25 <Neozonz> disc|for p2pool would it make sense to increase max connections so it can communicate with more pool nodes?
 99 2013-09-30 15:19:38 <forrestv> Neozonz|disc, p2pool makes its own p2p connections. its default is usually fine, but more can help
100 2013-09-30 15:20:06 <Neozonz> disc|any good numbers to go about tweaking?
101 2013-09-30 15:20:26 <sipa> Neozonz|disc: more nodes also means more relaying, so more bandwidth and latency
102 2013-09-30 15:21:01 <Neozonz> disc|I've got p2pool set at 1000, and bitcoind set at 125
103 2013-09-30 15:21:03 <CodeShark> which nodes you connect to is far more important than how many
104 2013-09-30 15:21:21 <Neozonz> disc|I've custom added local nodes as well
105 2013-09-30 15:21:34 <Neozonz> disc|just trying to bring down DOAs and stales
106 2013-09-30 15:21:36 <CodeShark> but you should connect to at least a few that are unlikely to be in collusion against you
107 2013-09-30 15:21:45 <Neozonz> disc|collusion against me?
108 2013-09-30 15:21:54 <CodeShark> well, speaking generally here
109 2013-09-30 15:21:58 <CodeShark> not specifically about bitcoind
110 2013-09-30 15:22:16 <CodeShark> collusion against you - as in deliberate withholding of messages
111 2013-09-30 15:22:27 <Neozonz> disc|ah
112 2013-09-30 15:22:44 <forrestv> Neozonz|disc, 1000 for p2pool is crazy and will use a ton of bandwidth .. something like a TB per month if you actually managed to find that many peers q:
113 2013-09-30 15:23:28 <Neozonz> disc|would it not be limited to 125 via bitcoind?
114 2013-09-30 15:23:40 <forrestv> no, p2pool peers are not the same as bitcoin peers
115 2013-09-30 15:23:42 <sipa> p2pool connections are independent from bitcoin connections
116 2013-09-30 15:23:45 <Neozonz> disc|ah
117 2013-09-30 15:23:58 <Neozonz> disc|interesting
118 2013-09-30 15:25:57 <Neozonz> disc|how come even when I've set p2pool to 1000, I'm only seeing  6/1 peers
119 2013-09-30 15:26:24 <sipa> finding peers is hard
120 2013-09-30 15:26:34 <sipa> or rather, having others find you is hard
121 2013-09-30 15:27:23 <Neozonz> disc|anyway to manually add p2pool nodes?
122 2013-09-30 15:27:58 <Neozonz> disc|I've manually added bitcoind nodes, but anyway to manually add p2pool nodes? (since the connections are separate)
123 2013-09-30 15:34:56 <michagogo> I think you can start with -n or something like that
124 2013-09-30 16:19:23 <maaku> CodeShark: i've been using scriptContract for scriptPubKey, and scriptEndorsement for scriptSig in my code
125 2013-09-30 16:41:02 <hobbes1981-00> Hello
126 2013-09-30 16:41:14 <hobbes1981-00> Does anyone here have experience calculating midstate?
127 2013-09-30 16:42:11 <Luke-Jr> hobbes1981-00: ?
128 2013-09-30 16:43:27 <MC1984> hello again
129 2013-09-30 16:48:01 <hobbes1981-00> In python I do this: 1) take the first 64 bytes of data 2) byteswap each 32 bit chunk 3) run decode('hex') to convert to raw bytes 4) run it through hashlib.sha256.hexdigest()
130 2013-09-30 16:48:21 <hobbes1981-00> That SHOULD work right? But it doesn't match up with the midstate returned from getwork
131 2013-09-30 16:48:25 <hobbes1981-00> I don't know what I'm doing wrong....
132 2013-09-30 16:48:26 <Luke-Jr> nope
133 2013-09-30 16:48:41 <Luke-Jr> it's not even possible to do it with hashlib
134 2013-09-30 16:49:01 <hobbes1981-00> Oh its not?
135 2013-09-30 16:49:09 <Luke-Jr> hashlib does the finalisation step
136 2013-09-30 16:49:24 <Luke-Jr> that's why there's a dedicated midstate C module
137 2013-09-30 16:49:39 <Luke-Jr> http://gitorious.org/midstate/midstate
138 2013-09-30 16:51:50 <hobbes1981-00> Ok, and once I calculate midstate using that C module I could use hashlib for the other step?
139 2013-09-30 16:52:09 <Luke-Jr> no?
140 2013-09-30 16:52:17 <Luke-Jr> what are you trying to do? O.o
141 2013-09-30 16:52:31 <Luke-Jr> the "other step" is done by dedicated hardware
142 2013-09-30 16:54:44 <hobbes1981-00> I'm just trying to write a simple hashing program. By "the other step" I mean setting the nonce and combining the second half of data with the midstate to run the 2nd hash and see if its lower than the target
143 2013-09-30 16:57:28 <Luke-Jr> hobbes1981-00: abandon Python then :p
144 2013-09-30 16:57:34 <Luke-Jr> hobbes1981-00: libblkmaker has an example
145 2013-09-30 17:33:44 <helo> has anyone examined web payments, and their relation to the payment protocol i.e. http://www.w3.org/community/webpayments/
146 2013-09-30 18:31:46 <midnightmagic> helo: web payments are IMO incompatible with normal bitcoin, as they seem to require an issuing authority that *other* people also accept, and they have a whole payment processing process which is either irrelevant in bitcoin, or useless in bitcoin, except if you want to interface with someone who doesn't have or want bitcoins.
147 2013-09-30 18:32:52 <midnightmagic> so, bitpay I bet could act as a payment authority, if other people agreed to trust they'd honour their payments and there was some way to *receive* payments from them. so, they have accounts with them or something like that.
148 2013-09-30 18:59:57 <helo> midnightmagic: yeah, they seem to be different worlds :/
149 2013-09-30 19:03:24 <midnightmagic> helo: p2p transfer of bitcoin is so trivial anyway, why bother including it in the browser? just do a link to whatever the bitcoin software running on the computer is.
150 2013-09-30 19:06:07 <helo> a locally running bitcoind/qt could maybe be viewed as the authority?
151 2013-09-30 19:14:40 <helo> why would my node be getting dozens of 'ERROR: CTxMemPool::accept() : inputs already spent' per second from a single node every now and then?
152 2013-09-30 19:15:17 <gmaxwell> because it's feeding you transactions that you're rejecting because they're double spends.
153 2013-09-30 19:15:56 <helo> well yeah, of course... is there some normal state of bitcoind that would cause it to do this?
154 2013-09-30 19:18:28 <swulf--> well, I'll be damned: I've got a working Bitcoin-Qt built with MSVC 2010
155 2013-09-30 19:18:47 <swulf--> took all day.. is this something that would be useful if I cleaned up and released the changes?
156 2013-09-30 19:20:30 <gmaxwell> swulf--: it depends.
157 2013-09-30 19:20:36 <swulf--> the new splash logo is nice
158 2013-09-30 19:21:22 <gmaxwell> swulf--: if the changes are fixes that are arguably wrong even in a universe where MSVC doesn't exist, great! if they're changes to add braindamage to appease it, thats less useful.
159 2013-09-30 19:21:38 <swulf--> the code changes are relatively minor
160 2013-09-30 19:21:57 <gmaxwell> swulf--: post patches?
161 2013-09-30 19:22:09 <swulf--> It's more a matter of putting together the build and getting 3rd party libraries built and linked properly
162 2013-09-30 19:22:33 <swulf--> gmaxwell: the most notorious change is indexing into vectors passed the end of the array
163 2013-09-30 19:22:47 <swulf--> lots of code like "&vch[vch.size()]" throws MSVC errors
164 2013-09-30 19:24:15 <swulf--> gmaxwell: but I've put together a small set of CMake files, which is probably going to be the part most of the devs don't want in the archive.  Worst case, I can just maintain a fork...
165 2013-09-30 19:36:03 <maaku> swulf--: we just moved to autotools
166 2013-09-30 19:36:10 <swulf--> maaku: Yeah, I'm aware
167 2013-09-30 19:36:19 <maaku> i'm not sure there'd be much support for a move to cmake
168 2013-09-30 19:36:31 <swulf--> maaku: these cmake files wouldn't work on *nix/osx
169 2013-09-30 19:36:49 <swulf--> in my mind, the cmake files would be for msvc-only builds
170 2013-09-30 19:36:50 <maaku> but a pull request with the msvc stuff would be appreciated by others, i'm sure
171 2013-09-30 19:36:56 <maaku> even if it never makes it in
172 2013-09-30 19:37:46 <swulf--> I still have to clean up the build, make sure the translations work, build tests.. so there's still more more work to do
173 2013-09-30 19:42:07 <gmaxwell> swulf--: In general I'm not sure that we want to do anything that potentially creates review workload for supporting a compiler we aren't going to test and support. Though the code cleanup is useful.
174 2013-09-30 19:44:38 <swulf--> Sure, makes sense
175 2013-09-30 20:30:11 <helo> can MSVC do deterministic builds?
176 2013-09-30 20:31:07 <helo> i would think MS's code/library signing fetish could be helpful for such a thing
177 2013-09-30 20:38:27 <Eneerge> that was weird
178 2013-09-30 20:38:35 <Eneerge> it said i couldnt change nick because banned in #bitcoin-dev
179 2013-09-30 20:38:36 <Eneerge> i part
180 2013-09-30 20:38:38 <Eneerge> change nick
181 2013-09-30 20:38:40 <Eneerge> rejoin without any issue
182 2013-09-30 22:52:14 <maaku> Eneerge: it's not just you
183 2013-09-30 22:52:35 <maaku> bitcoin-dev has some silly registered nick setting that prevents you from doing that
184 2013-09-30 23:08:45 <k9quaint> gmaxwell: OH YOU SNEAKY MANMUFFIN
185 2013-09-30 23:11:07 <sipa> ...?
186 2013-09-30 23:17:10 <gmaxwell> sipa: I edited one of his posts on the forum. (he tongue in cheek trolled me calling me fat, I changed it so his post said "my mommas fat")
187 2013-09-30 23:19:32 <midnightmagic> i thought the momma reference was odd..
188 2013-09-30 23:20:09 <phantomcircuit> gmaxwell, lol
189 2013-09-30 23:21:27 <MC1984> got to keep a sens eof humour about it
190 2013-09-30 23:23:45 <MC1984> I just put 0.8.5 on my bitcoin usb stick and it fails with "the runtime requested termination in an unusual manner" or some such
191 2013-09-30 23:23:48 <MC1984> is that a known thing
192 2013-09-30 23:24:04 <MC1984> i have -datadir as the usb stick obv
193 2013-09-30 23:37:33 <phantomcircuit> MC1984, iirc there is something that's linked dynamic in 0.8.5 that was static previously
194 2013-09-30 23:40:00 <MC1984> might that mean it would fail with a datadir from a previous version or something
195 2013-09-30 23:40:30 <phantomcircuit> MC1984, i dont think so
196 2013-09-30 23:40:39 <phantomcircuit> just possibly additional weirdness
197 2013-09-30 23:40:45 <phantomcircuit> (also i could be totally wrong)
198 2013-09-30 23:41:05 <MC1984> i could delete and start again but feh
199 2013-09-30 23:41:20 <MC1984> nobody like syncing dat chain
200 2013-09-30 23:50:27 <sneak> hi