1 2012-08-22 00:00:46 <weex> best thing about it, it has no issues. https://github.com/jgarzik/pynode/issues
2 2012-08-22 00:01:22 <lianj> weex: oO because its new ;)
3 2012-08-22 00:30:13 <jgarzik> lianj: pynode does the vast majority of that list
4 2012-08-22 00:30:30 <jgarzik> sebicas: pynode works on its own
5 2012-08-22 00:30:58 <sebicas> but doesn't work to send transactions, correct?
6 2012-08-22 00:31:05 <jgarzik> sebicas: pynode verifies everything except scripts by default. verifying scripts is a separate process, testscript.py
7 2012-08-22 00:31:17 <jgarzik> sebicas: correct. pynode does not create or send transactions.
8 2012-08-22 00:31:41 <jgarzik> it passively watches and verifies block chain information, and serves blockchain data to other nodes
9 2012-08-22 00:31:45 <sebicas> So I guess I can't have both..
10 2012-08-22 00:32:30 <sebicas> The problem is that I will need to have both a pynode & bitcoind
11 2012-08-22 00:32:44 <sebicas> Both will need to download block chain, etc
12 2012-08-22 00:32:54 <jgarzik> sebicas: yes
13 2012-08-22 00:33:00 <sebicas> So is like a waste of resources
14 2012-08-22 00:33:05 <jgarzik> sebicas: though if you have bitcoind, you probably do not need pynode?
15 2012-08-22 00:33:25 <sebicas> Yes, I am thinking in compile bitcoind myself
16 2012-08-22 00:33:47 <sebicas> And add some code that will publish the Block & Txs events to Amazon SNS
17 2012-08-22 00:34:16 <sebicas> It would be great to have kind of plugins for bitcoind to make it easy for add-ons like this
18 2012-08-22 00:34:47 <jgarzik> sebicas: ah! well pynode can be run without a blockchain database, if you _disable_ verification
19 2012-08-22 00:35:10 <jgarzik> sebicas: then you have bitcoind->pynode, and you may use pynode to send notifications when new blocks or tx's occur
20 2012-08-22 00:35:27 <jgarzik> that's one of pynode's purposes: monitoring the network
21 2012-08-22 00:35:32 <sebicas> So dynode will use the bitcoind database??? right?
22 2012-08-22 00:35:38 <sebicas> pynode
23 2012-08-22 00:36:04 <jgarzik> sebicas: of a sort. if pynode connects to a trusted bitcoind that you run, it does not need to query any database. it simply trusts its input.
24 2012-08-22 00:37:30 <sebicas> So basically I said to pynode??? only connect to my node, nothing else, listen to events and once you ear something publish it to AmazonSNS
25 2012-08-22 00:41:01 <jgarzik> sebicas: yep
26 2012-08-22 00:41:30 <jgarzik> sebicas: it's more a choice of programming language.. if you are comfortable modifying bitcoind, no need for pynode. but some might find it easier to write monitoring and glue code in python.
27 2012-08-22 00:42:06 <jgarzik> sebicas: note that bitcoind runs an executable or script for each block, with -blocknotify
28 2012-08-22 00:42:24 <sebicas> Yes, but doesn't give me transactions...
29 2012-08-22 00:42:26 <sebicas> Thx
30 2012-08-22 00:42:37 <jgarzik> nod
31 2012-08-22 00:43:10 <sebicas> The good thing about using pynode is that I can upgrade bitcoind and not worrying about my changes..
32 2012-08-22 00:43:22 <jgarzik> sebicas: transactions are contained within a block, so you get transactions too. you don't get zero-confirmation live transactions with -blocknotify, no.
33 2012-08-22 00:43:30 <jgarzik> sebicas: yep
34 2012-08-22 00:43:37 <sebicas> If I code in inside bitcoind every time there is a new real ease I will have to re-code it to upgrade..
35 2012-08-22 00:44:45 <jgarzik> sebicas: for something super-simple, you might even look at pynode's early history: https://github.com/jgarzik/pynode/tree/99af958516e9af246d35360ca8802c2bfd58c2e3
36 2012-08-22 00:45:01 <jgarzik> sebicas: e.g. https://github.com/jgarzik/pynode/blob/99af958516e9af246d35360ca8802c2bfd58c2e3/node.py
37 2012-08-22 00:45:46 <jgarzik> sebicas: all one file, just change code near the bottom where message.command=="tx" and message.command=="block"
38 2012-08-22 00:45:50 <sebicas> Great! Yes nice..
39 2012-08-22 00:46:02 <sebicas> Will need to add transactions events
40 2012-08-22 00:46:16 <jgarzik> sebicas: that's message.command=="tx"
41 2012-08-22 00:46:37 <jgarzik> sebicas: after the tx.is_valid() check
42 2012-08-22 00:47:56 <sebicas> Great! Thanks what is great!
43 2012-08-22 00:48:09 <sebicas> Thanks so much jgarzik!
44 2012-08-22 01:04:19 <Luke-Jr> now that CVE-2012-2459 is disclosed??? anyone recall which 0.6.1 RC was the real fix? :P
45 2012-08-22 01:14:35 <Luke-Jr> someone should probably update http://bitcoin.org/dos
46 2012-08-22 01:15:39 <Someguy123> Luke-Jr, "latest version: 0.6.2. "
47 2012-08-22 01:15:41 <gmaxwell> or just change it to a pointer to the CVE page for now.
48 2012-08-22 01:15:44 <Someguy123> yeah... maybe they should
49 2012-08-22 01:15:52 <Someguy123> atleast update the latest version
50 2012-08-22 01:15:57 <gmaxwell> pull requests accepted.
51 2012-08-22 01:21:43 <forrestv> Luke-Jr, git describe be8651d -> v0.6.1rc2
52 2012-08-22 01:49:18 <doublec> Luke-Jr: so eloipool had improvements bsaed on your inside knowledge of CVS-2012-2459 ?
53 2012-08-22 01:49:43 <doublec> that's a compelling reason for people to be using your pool
54 2012-08-22 01:49:51 <doublec> faster security fixes
55 2012-08-22 01:50:20 <Luke-Jr> doublec: well, if it was *really* important to patch the pool end, it would have been shared with all poolserver authors I'm sure
56 2012-08-22 01:51:33 <gmaxwell> I laughted at luke's silly little workaround. I don't think it mattered.
57 2012-08-22 01:52:22 <gmaxwell> But with all the paranoia about orphan blocks and such, I can't blame anyone from worrying.
58 2012-08-22 01:58:43 <jgarzik> wonder what orphan situation is like these days?
59 2012-08-22 01:58:51 <jgarzik> anything beyond anecdotal evidence?
60 2012-08-22 01:59:52 <doublec> I see a few people complain of nodes getting that WARNING message. Are they on old versions?
61 2012-08-22 02:00:43 <Luke-Jr> doublec: there's an annoying amount of stuck nodes just from disk corruption :/
62 2012-08-22 02:01:13 <jgarzik> bitcoind should validate a random block every hour ;)
63 2012-08-22 02:01:24 <Luke-Jr> jgarzik: I haven't done any analysis of myself in a few weeks, but I hear people are still noticing half-minute validation times
64 2012-08-22 02:01:59 <Luke-Jr> jgarzik: you probably have the skills needed to get block relaying done in realtime, want to give it a shot? :P
65 2012-08-22 02:02:28 <jgarzik> Luke-Jr: find me some ECDSA hardware and I'll write a driver
66 2012-08-22 02:02:30 <jgarzik> :)
67 2012-08-22 02:02:45 <Luke-Jr> haha, that won't do much good unless it's on most nodes tho >_<
68 2012-08-22 02:03:34 <Luke-Jr> IMO it'd be good enough if nodes relayed blocks in a more torrent-like fashon (ie, not waiting until you're done downloading, before starting to upload)
69 2012-08-22 02:03:35 <jgarzik> I should write a cnode client, based on pynode :)
70 2012-08-22 02:03:42 <jgarzik> just a "block router" and nothing else
71 2012-08-22 02:03:54 <Luke-Jr> ACTION would be interested to see a Bitcoin-Qt based on pynode, but that's another subject really
72 2012-08-22 02:04:57 <jgarzik> pull reqs accepted...
73 2012-08-22 02:09:36 <Luke-Jr> jgarzik: hopefully after this ASIC stuff is over I'll have more time ???
74 2012-08-22 02:13:02 <jgarzik> ha! just thought of a fun optimization for the C version of pynode:
75 2012-08-22 02:13:18 <jgarzik> store blk????.dat data as serialize block messages, not just serialized blocks
76 2012-08-22 02:13:30 <jgarzik> then you may sendfile(2) the entire message from disk
77 2012-08-22 02:13:44 <jgarzik> a C router doing that would hum...
78 2012-08-22 02:15:05 <Luke-Jr> :D
79 2012-08-22 02:15:24 <jgarzik> rip through pagecache with zero copying, straight to network
80 2012-08-22 02:15:51 <jgarzik> of course, pynode could do that too, but C makes it easier to do things with minimal buffer copying
81 2012-08-22 02:16:25 <jgarzik> sipa gmaxwell: ^^ bitcoind could do this
82 2012-08-22 02:16:48 <jgarzik> incompatible with existing blk????.dat format sadly
83 2012-08-22 02:18:05 <Luke-Jr> windows even has an equivalent: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).aspx
84 2012-08-22 02:18:29 <Luke-Jr> jgarzik: couldn't you just send the message header and still use sendfile?
85 2012-08-22 02:18:31 <jgarzik> of course. they invented TSO
86 2012-08-22 02:18:57 <jgarzik> Luke-Jr: yes, you send header with MSG_MORE... but there is the annoying checksum at the end
87 2012-08-22 02:19:04 <jgarzik> it's also more syscalls and context switches
88 2012-08-22 02:19:11 <Luke-Jr> ah right
89 2012-08-22 02:19:39 <Luke-Jr> I suppose we could cache block checksums to some degree
90 2012-08-22 02:19:49 <jgarzik> hmmm
91 2012-08-22 02:20:07 <jgarzik> I think you could add a checksum trailer without breaking file format compat
92 2012-08-22 02:20:24 <jgarzik> should get ignored
93 2012-08-22 02:21:18 <jgarzik> ChainDb: height 195092, block 000000000000050df9f6189625cdd504924d221f6682b7fa507b478487b2cfd6
94 2012-08-22 02:21:24 <jgarzik> hrmph
95 2012-08-22 02:23:20 <jgarzik> SIGH
96 2012-08-22 02:23:25 <jgarzik> ACTION bangs head on brick wall
97 2012-08-22 02:23:32 <jgarzik> ppcoin did not change pchMessageStart
98 2012-08-22 02:23:41 <gmaxwell> yup.
99 2012-08-22 02:23:45 <Luke-Jr> jgarzik: yes, I noticed that
100 2012-08-22 02:23:53 <Luke-Jr> are PPCoin nodes getting banned now? XD
101 2012-08-22 02:24:31 <gmaxwell> Hey, I suggested that the screwyness of testnet was a good reason to actually make things suck less with respect to that. :)
102 2012-08-22 02:27:05 <jgarzik> isn't there a Dummies Guide to Creating An Alt Coin at this point?
103 2012-08-22 02:27:14 <jgarzik> even the scammers got that detail right
104 2012-08-22 02:28:09 <jgarzik> and my, my. poold.py seems to be popping up all over, too.
105 2012-08-22 02:31:36 <copumpkin> not very helpful message :( http://snapplr.com/h4yx
106 2012-08-22 02:40:31 <jgarzik> ACTION reads http://krebsonsecurity.com/2012/08/inside-the-grum-botnet/ and wonders what is the smallest (source code size) useful encryption system that a botnet could use for secure communications. anything smaller than AES?
107 2012-08-22 02:41:39 <jgarzik> I always have imagined working on an autonomous agent that was composed of many "cells" -- each a program running on a host -- that communicated together to form a narrow AI hive mind
108 2012-08-22 02:43:31 <jgarzik> ACTION looked at Parrot (parrot.org) as a candidate for such an agent. A simple VM, which can download crypto-signed updates of its "brain" / "DNA" and update itself, possibly JIT'ing along the way
109 2012-08-22 02:43:44 <gmaxwell> jgarzik: hey, on newer processeors AES is really small! :)
110 2012-08-22 02:43:52 <jgarzik> hehehe
111 2012-08-22 02:44:30 <gmaxwell> "You're telling me that ... the phonenumber I dialed ... overflowed a buffer and encrypted my system and is now holding it for randsom????"
112 2012-08-22 02:45:36 <Luke-Jr> jgarzik: truly antonomous would be interesting
113 2012-08-22 02:45:51 <Luke-Jr> jgarzik: Eligius's final DDoS was some pretty complicated botnet stuff tho
114 2012-08-22 02:46:05 <Luke-Jr> I don't think the FBI ended up getting anywhere with it :/
115 2012-08-22 02:46:07 <doublec> jgarzik: how about wasp list?
116 2012-08-22 02:46:12 <doublec> s/list/lisp/
117 2012-08-22 02:46:20 <gmaxwell> Luke-Jr: You mean the ... attack of the flying HP printers? :)
118 2012-08-22 02:46:24 <jgarzik> I despise lisp with a passion ;p
119 2012-08-22 02:46:34 <doublec> https://sites.google.com/site/waspvm/
120 2012-08-22 02:46:44 <Luke-Jr> gmaxwell: yes, but those were just masking the real bots :P
121 2012-08-22 02:47:19 <doublec> it was used to build mosref. A penetration testing framework where you have a master console that sends out drones to hosts
122 2012-08-22 02:47:25 <doublec> and sends compiled lisp code to the drones
123 2012-08-22 02:47:41 <doublec> http://www.bluishcoder.co.nz/2009/11/28/using-wasp-lisp-secure-remote-injection.html
124 2012-08-22 02:48:12 <doublec> drones talk to the console via an encrypted channel using the salsa20 stream cipher
125 2012-08-22 02:49:04 <jgarzik> ACTION wonders... does TEA live up to its acronym? :) http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
126 2012-08-22 02:49:14 <gmaxwell> jgarzik: ask msft?
127 2012-08-22 02:49:23 <gmaxwell> (asn't TEA what got the first gen xboxes compromised?
128 2012-08-22 02:49:25 <gmaxwell> )
129 2012-08-22 02:49:35 <jgarzik> according to WP yes :)
130 2012-08-22 02:50:31 <jgarzik> but there are inevitable fixes and extensions
131 2012-08-22 02:53:25 <jgarzik> ChainDb: height 195096, block 00000000000007a142b00794b462423707e94137c9232b31967445dded82616d
132 2012-08-22 02:54:03 <Diablo-D3> vat is that
133 2012-08-22 02:54:48 <jgarzik> a miner not contributing to the network
134 2012-08-22 02:55:19 <Diablo-D3> vhy not?
135 2012-08-22 02:55:37 <Diablo-D3> and vhy am I talking in such a ridiculous german accent
136 2012-08-22 03:26:13 <dust-otc> blockchain.info having problems?
137 2012-08-22 03:26:32 <dust-otc> last block 1hr 30min ago?
138 2012-08-22 03:27:57 <gmaxwell> ;;bc,tslb
139 2012-08-22 03:27:57 <gribble> Time since last block: 30 seconds
140 2012-08-22 03:28:10 <gmaxwell> "Haha"
141 2012-08-22 03:40:58 <Lilliana> Hey. I'm very interested in bitcoin development and curious, partly to learn what it's all about and what it means. And mostly the actual code that goes into it.
142 2012-08-22 03:41:24 <Lilliana> So question #1 what is the purpose behind bitcoin and what are bitcoins. I have a friend who's always going on about it but he leaves details out and doesn't entirely seem to know what it is/about.
143 2012-08-22 03:41:36 <Lilliana> Question #2 What language is it being developed in, depending on my skills.
144 2012-08-22 03:41:39 <Lilliana> I can offer some help.
145 2012-08-22 03:45:40 <gjs278> Lilliana it's c++ and it's for sending money to people through computers and avoiding central authorities
146 2012-08-22 03:46:11 <Lilliana> I just watched the video.
147 2012-08-22 03:46:27 <midnightmagic> TD[gone]: hey, your bitcoin-leveldb managed to corrupt itself (possibly with the host machine's help) and can no longer read the blockindex.
148 2012-08-22 03:47:04 <Lilliana> Ok, I'm curious about one thing. How does the bitcoin mining work and how is the limit set? I guess I shouldn't be asking this here. How is the market value exchange of bitcoins determined? As comparable to any other currency?
149 2012-08-22 03:48:32 <midnightmagic> Lilliana: what limit?
150 2012-08-22 03:50:44 <Lilliana> In the video it said something about limiting how many bitcoins could be produced or something, to balance bitcoin value.
151 2012-08-22 03:53:34 <jgarzik> Lilliana: this is offtopic for #bitcoin-dev. try #bitcoin... To answer your question, the market value is determined by ... the market :) There is a free exchange at all times between buyers and sellers.
152 2012-08-22 03:54:03 <jgarzik> Lilliana: also https://en.bitcoin.it/wiki/FAQ
153 2012-08-22 03:57:55 <Lilliana> Alright here's a better question. How can I help with development of the bit coin system?
154 2012-08-22 04:02:34 <gjs278> first you must understand it
155 2012-08-22 04:02:41 <gjs278> then you have to think of a feature you want that doesnt exist
156 2012-08-22 04:13:26 <Lilliana> Right now i'm reading the paper. Some interesting math, not all of it I understand.
157 2012-08-22 04:14:00 <gmaxwell> 23:02 < gjs278> then you have to think of a feature you want that doesnt exist
158 2012-08-22 04:14:21 <gmaxwell> actually, then you must use it a bunch and find all the bugs in the many features we already have! :)
159 2012-08-22 04:14:21 <Lilliana> I can see though that the assumed cpu power required to over ride or pull the wool over the rest of the network's eyes , is so great the odds are basically none for faults.
160 2012-08-22 04:14:44 <gjs278> I only have one successful pull request, it was for a new feature, but yes, you could fix the existing ones
161 2012-08-22 04:14:49 <Lilliana> I also like how the blocks are encrypted so that it actually takes alot of cpu work to re-work the hashes.
162 2012-08-22 04:17:54 <Lilliana> It's interesting. =p =p
163 2012-08-22 04:18:03 <Lilliana> I just finished reading the paper.
164 2012-08-22 04:26:30 <amiller> gmaxwell, what would it take to 'merge mine' on two forks while also reducing your payout proportionally?
165 2012-08-22 04:26:54 <amiller> for example, if your threshold calculation is based on the sum of the difficulties
166 2012-08-22 04:26:56 <gmaxwell> A coin that could mergemine with itself.
167 2012-08-22 04:27:14 <amiller> that way you would be able to split your bet across two forks if you aren't sure what will be chosen
168 2012-08-22 04:28:01 <amiller> something that wins in one fork would need to be mutually exclusive to a winner in the other fork
169 2012-08-22 04:28:01 <gmaxwell> e.g. if it accepted two block types, a mergmined block and a direct block. You'd direct mine one, mergemine the other(s). but you might be interested in a post I _Just_ made, where I basically argue against that kind of dillution.
170 2012-08-22 04:28:11 <gmaxwell> amiller: see https://bitcointalk.org/index.php?topic=102355
171 2012-08-22 04:28:14 <amiller> er, yeah, i meant to reference that post
172 2012-08-22 04:28:17 <gmaxwell> ah hah.
173 2012-08-22 04:29:20 <amiller> its a waste of your effort not to validate both of them
174 2012-08-22 04:30:45 <gmaxwell> a waste, but getting good convergence requires that you're not validating everything. At a minimum a viable scheme has to make it cost you something to spread yourself out. E.g. half your reward.
175 2012-08-22 04:31:06 <amiller> what if you validate two chains in parallel
176 2012-08-22 04:31:11 <amiller> and bet on them in proportion to how far along in your validation
177 2012-08-22 04:31:23 <amiller> work first
178 2012-08-22 04:32:15 <amiller> only strong proof of work could make you waste time validating a transaction, and by 66% assumption there isn't a longer chain than _both_ the ones you're validating
179 2012-08-22 04:36:59 <amiller> someone who gets a block in one of the chains is effectively documenting the existence of the other fork
180 2012-08-22 04:37:32 <Lilliana> kay guys this computational theory talk is really making me excited. I love this type of stuff.
181 2012-08-22 04:45:42 <gmaxwell> amiller: I do generally like the ideas where you are incentivized to expose people to forks... simply because it aligns a consensus-incentive with the consensus-requirement of information availablity.
182 2012-08-22 04:45:57 <gmaxwell> amiller: but I do not like the bandwidth consequences.
183 2012-08-22 04:47:09 <amiller> can you isolate what bandwidth consequences we'd run into?
184 2012-08-22 04:47:34 <amiller> i'm trying to split the worry into two parts, transaction validation and work validation at least
185 2012-08-22 04:47:48 <amiller> the worst case with transaction validation is that you might get stuck with missing data
186 2012-08-22 04:49:05 <amiller> you might be looking at a fork that you cannot make progress in validating
187 2012-08-22 04:49:26 <gmaxwell> amiller: right if you only passed some header, then you're not really making the fork available to me.
188 2012-08-22 04:50:00 <gmaxwell> So that benefit I mentioned doesn't exist. someone who wants to isolate you and feed you a shorter chain could refuse to let you validate the longer one but still benefit from it.
189 2012-08-22 04:51:13 <amiller> if he can't isolate you forever then you'll eventually switch, and you'll have put at most half of your power on an invalid chain
190 2012-08-22 04:51:29 <amiller> someone who isolates you can't trick you into double-working
191 2012-08-22 04:52:08 <amiller> he can't get you to put all of your mining in one invalid chain as long as you're aware of the second's headers
192 2012-08-22 04:59:12 <amiller> eventually we're going to want to have users demand a minimum difficulty in order for the fees to be valid, and this sort of balancing act is going to what keeps it stable
193 2012-08-22 05:00:29 <amiller> if the fees are cheap to win, then you'll have more miners splitting their work on forks, and your transactions risk getting forked
194 2012-08-22 05:01:14 <amiller> by increasing your minimum-difficulty demand for your fees, when you get included in a block it's less likely you'll be forked
195 2012-08-22 05:25:56 <Cryo_> someone annoy blockexplorer?
196 2012-08-22 07:57:35 <sipa> jgarzik: well, it's still possible to use sendfile to send the actual block data after sending some headers the normal way, no?
197 2012-08-22 07:58:42 <sipa> and isn't the checksum in front instead of at the end?
198 2012-08-22 08:54:46 <denisx> [7]: biste schon fertig mit ppcoin?
199 2012-08-22 08:54:58 <denisx> ops, fc
200 2012-08-22 09:54:42 <sipa> wow, we have already >600 commits since v0.6.0 (excluding merges)
201 2012-08-22 09:54:54 <sipa> between v0.5.0 and v0.6.0 there were 292
202 2012-08-22 09:55:23 <sipa> between v0.4.0 and v0.5.0 there were 454
203 2012-08-22 09:59:12 <wumpus> wow
204 2012-08-22 10:00:28 <sipa> between v0.3.19 (+- when gavin took over) and v0.4.0, there were 536
205 2012-08-22 10:01:37 <sipa> maybe size of diffs is a more accurate metric
206 2012-08-22 10:04:29 <JyZyXEL> in bitcoin wiki it says nonce is only a 32-bit field, wouldn't that be much too fast to go trough? and what if none of those values produces a hash that is acceptable?
207 2012-08-22 10:05:05 <sipa> JyZyXEL: then you ask for more work
208 2012-08-22 10:05:11 <JyZyXEL> and in blockexplorer.com for nonce the description says "When generating, Bitcoin starts this number at 1 and increments for each hash attempt.", wouldn't that mean the fastest hasher always wins
209 2012-08-22 10:05:14 <sipa> and search the nonce for another block
210 2012-08-22 10:05:29 <sipa> no, because every miner searches a different range
211 2012-08-22 10:05:41 <sipa> they are just not working on the same block
212 2012-08-22 10:09:11 <JyZyXEL> so you keep adding transactions to the block your working on?
213 2012-08-22 10:09:54 <sipa> no, but you can change the coinbase transaction
214 2012-08-22 10:10:13 <sipa> 1) by changing who to pay to (which differs already for every miner)
215 2012-08-22 10:10:31 <sipa> 2) by changing the coinbase input (up to 100 bytes which are otherwise completely ignored)
216 2012-08-22 10:12:22 <JyZyXEL> what controls then how many transactions there are in the block?
217 2012-08-22 10:13:52 <sipa> the miner
218 2012-08-22 10:16:28 <t7> and the network wont accept it?
219 2012-08-22 10:16:36 <t7> if its over 1 meg or whatever
220 2012-08-22 10:24:03 <sipa> wumpus: apart from the the few very recent commits, anything you think is still wanted/viable for 0.7.0rc1?
221 2012-08-22 10:25:44 <sipa> i'd say: 1700, 1699, 1698, 1694, 1672, 1670, 1409
222 2012-08-22 10:26:22 <wumpus> let me go over the list
223 2012-08-22 10:26:50 <JyZyXEL> https://en.bitcoin.it/wiki/Block_hashing_algorithm
224 2012-08-22 10:27:06 <sipa> t7: they still have to produce *valid* blocks of course
225 2012-08-22 10:27:11 <JyZyXEL> "extraNonce"
226 2012-08-22 10:27:22 <sipa> JyZyXEL: that's what i called coinbase input before
227 2012-08-22 10:27:45 <JyZyXEL> the table doesn't even list those as belonging in the block header
228 2012-08-22 10:27:52 <sipa> they don't
229 2012-08-22 10:28:11 <t7> its time for bitcoin 2.0
230 2012-08-22 10:28:21 <t7> with simpler protocol
231 2012-08-22 10:28:22 <sipa> the coinbase input is part of the coinbase (=the first transaction in a block), which only influences the block header indirectly via the merkle root of the transaction list
232 2012-08-22 10:28:39 <t7> written in coq
233 2012-08-22 10:28:44 <sipa> t7: be my guest
234 2012-08-22 10:28:52 <wumpus> sipa: I agree on those
235 2012-08-22 10:29:02 <JyZyXEL> oh i see
236 2012-08-22 10:29:30 <wumpus> yes, let's make a client in yet another programming language, that will teach them!
237 2012-08-22 10:29:51 <t7> maybe seeded with the original blockchain.... but still everyone would have to move at once, and i don't think everyone will
238 2012-08-22 10:30:17 <wumpus> let's first try to make everyone on earth jump at once
239 2012-08-22 10:32:17 <t7> maybe just another *coin then :(
240 2012-08-22 10:32:54 <sipa> there are many potential improvements that have been discovered since its creation, which would improve bitcoin in theory
241 2012-08-22 10:33:06 <sipa> but few of them solve an actual problem for now
242 2012-08-22 10:33:14 <JyZyXEL> what does it mean when it says the Merkle root is updated when "a transaction is accepted"
243 2012-08-22 10:33:30 <sipa> JyZyXEL: you understand the merkle tree?
244 2012-08-22 10:33:33 <JyZyXEL> yeah
245 2012-08-22 10:33:39 <wumpus> yes, most is busywork
246 2012-08-22 10:34:21 <sipa> JyZyXEL: so everytime a new transaction is accepted to the memory pool, new blocks constructed are based on the modified merkle root of the accepted transactions
247 2012-08-22 10:34:35 <sipa> hi there gavin; i just said to wumpus:
248 2012-08-22 10:34:42 <sipa> wumpus: apart from the the few very recent commits, anything you think is still wanted/viable for 0.7.0rc1?
249 2012-08-22 10:34:46 <sipa> i'd say: 1700, 1699, 1698, 1694, 1672, 1670, 1409
250 2012-08-22 10:34:57 <JyZyXEL> who accepts these new transactions, based on what and where do they come from?
251 2012-08-22 10:36:24 <wumpus> I also don't think simplifying the protocol is a goal in itself, though it'd be nice to not let it become even more byzantine
252 2012-08-22 10:36:42 <sipa> JyZyXEL: anyone accepts transactions to their memory pool, which 1) do not conflict with the blockchain 2) do not conflict with what is already in their mempool
253 2012-08-22 10:36:52 <sipa> JyZyXEL: miners use the mempool to create blocks from
254 2012-08-22 10:37:03 <sipa> others use it as a list of transactions with 0 confirmations
255 2012-08-22 10:37:16 <sipa> oh, 3) are otherwise valid
256 2012-08-22 10:37:44 <JyZyXEL> well im guessing these transactions just somehow spread in the network?
257 2012-08-22 10:37:48 <sipa> yes
258 2012-08-22 10:37:54 <sipa> it's a gossip network
259 2012-08-22 10:38:02 <sipa> nodes tell eachother what they know
260 2012-08-22 10:43:12 <JyZyXEL> ok so solo mining seems pretty straight forward then
261 2012-08-22 10:44:27 <gavinandresen> we need to do something nice for BlueMatt... I'm LOVING BitcoinPullTester automatic pull testing!
262 2012-08-22 10:44:42 <sipa> ACTION too
263 2012-08-22 10:56:27 <wumpus> yes it's very useful
264 2012-08-22 11:31:56 <yesyesja> can anybody help me with bit-pay?
265 2012-08-22 12:12:35 <gmaxwell> sipa: I'm happy to see so many people misreading your patch; proves people are actually reading all these things (if not all that carefully)
266 2012-08-22 12:12:44 <sipa> gmaxwell: indeed!
267 2012-08-22 12:16:07 <roconnor> sipa: *ping*
268 2012-08-22 12:16:14 <sipa> roconnor: yes?
269 2012-08-22 12:17:11 <roconnor> sipa: since duplicate transactions are disallowed, don't we need a TXO database rather than an UTXO database? If you don't keep (some information) about spent transactions you won't know if there is a duplicate or not.
270 2012-08-22 12:18:28 <sipa> roconnor: BIP30 explicitly allows a duplicate transaction if the original one was fully spent already
271 2012-08-22 12:18:36 <roconnor> ah
272 2012-08-22 12:18:42 <sipa> (specifically in order not to prevent pruning in the future)
273 2012-08-22 12:18:46 <roconnor> right
274 2012-08-22 12:18:48 <roconnor> thanks
275 2012-08-22 12:19:26 <sipa> we're now adding a new rule even, to include the height in coinbases
276 2012-08-22 12:19:36 <sipa> which would guarantee full uniqueness
277 2012-08-22 12:19:45 <roconnor> good
278 2012-08-22 12:19:53 <roconnor> it will be useful for other things too I think
279 2012-08-22 12:20:13 <sipa> the uniqueness is good, but i'm not sure it's actually useful
280 2012-08-22 12:22:28 <gmaxwell> well, it's useful in that it avoids making things that think txid is unique vulnerable to varrious attacks!
281 2012-08-22 12:22:29 <sipa> (in my implementation of the UTXO set, i even keep heights of each tx(output) separately)
282 2012-08-22 12:34:02 <gmaxwell> wumpus: I didn't mean to imply we shouldn't do the mlock improvemens; good work. I was just pouting about the fact that it isn't nearly enough.
283 2012-08-22 12:35:34 <wumpus> gmaxwell: I think we can protect jsonrpc (except for the network path, maybe over SSL it could be fully protected).. qt, however, will become difficult, I don't know of any "secure input" initiatives
284 2012-08-22 12:36:36 <gmaxwell> wumpus: for -qt the possibility there would be for fork+exec a input getting process and mlockall the thing. Then have it feed the key to json rpc, assuming thats a solved problem.
285 2012-08-22 12:36:47 <gmaxwell> Though making jsonrpc a solved problem sounds hard to me.
286 2012-08-22 12:37:21 <wumpus> I wonder what will be the impact of only using securestring in jsonrpc :-)
287 2012-08-22 12:37:27 <gmaxwell> ugh.
288 2012-08-22 12:38:09 <gmaxwell> wumpus: I think to be remotely viable we'd have to go back to your option (1); though perhaps not boost pool.. but at least some other external malloc.
289 2012-08-22 12:38:10 <wumpus> or maybe add an additional layer of encryption on the password as it goes through jsonrpc
290 2012-08-22 12:38:17 <gmaxwell> mlock is _slow slow slow_ on some systems.
291 2012-08-22 12:39:22 <gmaxwell> I have some Linux/amd64 system were it takes multiple milliseconds (presumably due to TLB flushes)
292 2012-08-22 12:39:40 <gavinandresen> instead of spending lots of time trying to make the single-compromised-machine case secure, I'd rather we spent lots of time getting a multi-device solution running
293 2012-08-22 12:39:42 <wumpus> well at least my patch reduces the number of mlock/munlock calls a lot
294 2012-08-22 12:40:08 <wumpus> but yeah using it for all the string handling in jsonrpc would be a joke
295 2012-08-22 12:40:50 <wumpus> jsonrpc performance is already a pain point for some
296 2012-08-22 12:40:55 <gmaxwell> gavinandresen: what, you're not expecting grandma to do raw transaction api mediated offline wallets as soon as 0.7 is out?? ( my first draft of a walkthrough: http://people.xiph.org/~greg/signdemo.txt )
297 2012-08-22 12:41:36 <gavinandresen> I saw the walkthrough, nice!
298 2012-08-22 12:41:52 <gmaxwell> But fair point. Further hardening there is less important than other things we could do, like offline wallets, multisign devices, wallet process seperation, paper encryption backups, etc.
299 2012-08-22 12:42:14 <gavinandresen> much, much, much less important IMHO
300 2012-08-22 12:43:00 <gavinandresen> keyloggers are a much bigger worry for me than "I found your private key in swap space on that hard disk you threw away..."
301 2012-08-22 12:43:31 <gmaxwell> (in fact with wallet process seperation... it might even by viable to mlock the whole wallet process, if its memory usage can be gotten low enough, so maybe an improvement here comes almost for free later)
302 2012-08-22 12:43:51 <gavinandresen> or we could just tell people to run with whole-disk encryption.
303 2012-08-22 12:44:07 <gmaxwell> Good advice generally.
304 2012-08-22 12:44:39 <gmaxwell> (I once got a HDD RMA replaced that came back with only the first few sectors zeroed, the rest had someone elses data on it)
305 2012-08-22 12:44:57 <gmaxwell> (You can't erase a failed disk, so I encrypt all my disks now)
306 2012-08-22 12:45:12 <wumpus> at least mlock/munlock is now working as it was supposed to, I'll leave it at there, next is getting that fstack-protector-all working on mingw
307 2012-08-22 12:45:46 <wumpus> yes, good point
308 2012-08-22 12:45:57 <gmaxwell> wumpus: Did you see that post to pidgin-otr by Jacob that I linked to?
309 2012-08-22 12:46:14 <gavinandresen> I worked out my Mac build environment issues, so am ready to build 0.7rc1 whenever we colletively decide it is good enough.
310 2012-08-22 12:46:57 <gavinandresen> (hmmm, before 0.7 final we should get a signing certificate from Apple...)
311 2012-08-22 12:48:08 <wumpus> gmaxwell: yes, he got it to work with even more hardening options... I'm trying with a newer version of mingw, I'm almost sure that will solve the problem
312 2012-08-22 12:49:00 <gmaxwell> wumpus: I think I mentioned before, but I had no issues building C stuff with SSP on mingw; well no issues beyond the need to explicitly link libssp; but this was on quite new mingw.
313 2012-08-22 12:49:21 <BlueMatt> gavinandresen: heh, thanks
314 2012-08-22 12:49:52 <gmaxwell> At some point we do need to advance our build enviroment, e.g. we'll get things like LTO in new GCC will make smaller and faster binaries; mingw thats less buggy, etc.
315 2012-08-22 12:51:02 <BlueMatt> gmaxwell: Ive been xcompiling on my system using mingw-w64 (a significantly newer version), we could probably reasonable switch to that (though I have yet to test it with ssp stuff)
316 2012-08-22 12:52:55 <wumpus> yes I'm also using mingw-w64 (in 32 bit mode) now
317 2012-08-22 12:53:12 <gmaxwell> BlueMatt: what GCC version is that?
318 2012-08-22 12:53:23 <wumpus> 4.7
319 2012-08-22 12:53:27 <BlueMatt> on my system, 4.6.3
320 2012-08-22 12:53:49 <wumpus> oh ,right
321 2012-08-22 12:54:01 <BlueMatt> same on precise, but its probably newer in experimental
322 2012-08-22 12:54:10 <gmaxwell> okay, well 4.6 and later is IIRC where LTO is actually useful.
323 2012-08-22 12:55:36 <BlueMatt> but, yea, lto is hugely useful for bitcoin
324 2012-08-22 12:55:52 <BlueMatt> (at least in my brief tests)
325 2012-08-22 12:56:31 <gmaxwell> (though, ... I bet I can't actually compile bitcoin with LTO on my laptop; at least not without going deep into swap)
326 2012-08-22 12:57:08 <BlueMatt> works fine here with 8g
327 2012-08-22 12:57:14 <BlueMatt> (and no swap)
328 2012-08-22 12:57:30 <sipa> gmaxwell, gavinandresen, wumpus, BlueMatt: what do you guys think about removing the random-number-of-stack frames created for new threads?
329 2012-08-22 12:57:40 <sipa> i believe there was evidence that GCC even optimized that away
330 2012-08-22 12:57:47 <wumpus> I really dispise that code
331 2012-08-22 12:58:17 <sipa> in combination with hardening flags, i doubt it adds anything at all
332 2012-08-22 12:58:19 <BlueMatt> sipa: dunno, gdb has always seemed to indicate that it works
333 2012-08-22 12:58:25 <gmaxwell> 'meh'. I'd rather fix it than remove it if it's being optimized away. Is it really a nussance? (well, other than we now miss it on some threads...)
334 2012-08-22 12:58:32 <gavinandresen> I wrote a replacement a while ago as part of a "use boost::thread" branch that I never finished....
335 2012-08-22 12:58:51 <wumpus> I somehow remember the code wasn't even thread safe
336 2012-08-22 12:59:11 <gavinandresen> another not-a-high-priority-to-fix, I think
337 2012-08-22 12:59:13 <sipa> wumpus: indeed, i remember that too, though i forget the details
338 2012-08-22 12:59:20 <sipa> well, it's trivial to remove :)
339 2012-08-22 13:00:51 <gavinandresen> I'd vote to keep it. Doesn't hurt anything, might help.
340 2012-08-22 13:01:41 <wumpus> sipa: btw, do you really need to use a cryptologically secure random number generator in addrman? it was using a lot of CPU time to choose the same node every time here :-)
341 2012-08-22 13:01:46 <gavinandresen> (no reason for every new use of threads to use it, though)
342 2012-08-22 13:01:49 <gmaxwell> sipa: it's certantly less important when coupled with the other hardening; when it actually works; though it doesn't today one windows.
343 2012-08-22 13:02:05 <gmaxwell> s/one/on
344 2012-08-22 13:02:47 <sipa> wumpus: for picking addresses to connect to, it doesn't matter
345 2012-08-22 13:03:50 <wumpus> maybe the looping patch fixes that, though, haven't tried yet
346 2012-08-22 13:04:20 <wumpus> but GetRand is really, really slow
347 2012-08-22 13:04:42 <sipa> yeah, maybe we need a GetRand and GetRandSecure
348 2012-08-22 13:05:45 <gmaxwell> I think there are relatively few non-secure rand uses in bitcoin, at least if we're being fairly paranoid.
349 2012-08-22 13:06:23 <gmaxwell> (though yea, peer selection ... but then again peer selection should consume fairly little random data)
350 2012-08-22 13:06:59 <wumpus> maybe call them GetRand and GetRandInsecure
351 2012-08-22 13:07:24 <wumpus> :p
352 2012-08-22 13:07:44 <wumpus> also a plain old rand() is used in ApproximateBestSubset in wallet.cpp
353 2012-08-22 13:08:39 <wumpus> that one uses a lot of random data and doesn't need to be secure
354 2012-08-22 13:12:31 <gmaxwell> gavinandresen: darn, we never made the non-canonical signatures non-standard? I thought that got done a while ago.
355 2012-08-22 13:14:26 <gavinandresen> gmaxwell: never implemented. I think I've got a piece of paper on my desk somewhere with the openssl calls to do encode(decode()) to check for canonical-ity
356 2012-08-22 13:15:27 <gmaxwell> though encode(decode()) doesn't save us from "openssl is exploitable".
357 2012-08-22 13:15:59 <sipa> i'd rather have a very well-defined rule for which byte sequences are valid as signatures and pubkeys
358 2012-08-22 13:16:07 <sipa> that doesn't depend on an OpenSSL call
359 2012-08-22 13:16:45 <gavinandresen> Are DER-encoded signatures always fixed length?
360 2012-08-22 13:17:02 <gmaxwell> These things are not mutually exclusive. E.g. it could do both a simple sanity check as well as the encode(decode())
361 2012-08-22 13:17:12 <BlueMatt> gavinandresen: i dont believe so
362 2012-08-22 13:17:28 <sipa> gavinandresen: no, but someone in that thread describes the exact format
363 2012-08-22 13:17:36 <BlueMatt> (at least due to the negative-as-positive bug)
364 2012-08-22 13:17:56 <gmaxwell> BlueMatt: well, we should make those non-standard too.
365 2012-08-22 13:18:03 <BlueMatt> absolutely
366 2012-08-22 13:18:46 <gavinandresen> this is why I haven't implemented it yet, I haven't had time to get the nitty-gritty details of exactly what's in a signature....
367 2012-08-22 13:19:13 <sipa> also, prevent extra bytes at the end (or before the sighashtype byte in signatures)
368 2012-08-22 13:19:32 <sipa> not allowing zeroes in front of r and s in signatures
369 2012-08-22 13:19:43 <sipa> hybrid pubkey encodings
370 2012-08-22 13:19:54 <BlueMatt> sipa: unless [0] & 0x80
371 2012-08-22 13:20:00 <gavinandresen> encode(decode()) would catch all that, right? Not a negative r or s (can they be negative?)
372 2012-08-22 13:20:07 <sipa> gavinandresen: right
373 2012-08-22 13:20:12 <sipa> whatever type pubkey encodings openssl invents in the future
374 2012-08-22 13:20:20 <BlueMatt> gavinandresen: dunno about negative, depends on openssl's encodings in biginteger
375 2012-08-22 13:23:14 <gavinandresen> I'm headed to NYC soon for the big meetup tonight. sipa, any chance you can take a crack at an IsCanonicalSignature() function?
376 2012-08-22 13:24:12 <sipa> i'll see what i can do
377 2012-08-22 13:24:56 <gavinandresen> A CScript.IsCanonical() would be nifty, too (check for things like using OP_PUSHDATA1 to push a small constant)
378 2012-08-22 13:26:20 <sipa> that feels wrong
379 2012-08-22 13:26:34 <sipa> ideally, scripts are either valid or invalid with nothing in between
380 2012-08-22 13:26:55 <BlueMatt> sipa: IsStandard has to come first...by a lot
381 2012-08-22 13:27:03 <sipa> we have isstandard now as a countermeasure, but i hope we don't need that forever
382 2012-08-22 13:27:40 <sipa> an iscanonical does fit within the template-matching stuff, were it can return "this is a standard template, but there is something weird with it"
383 2012-08-22 13:30:10 <gavinandresen> I'm still worried about changing transaction ids by tweaking scriptSigs before relaying
384 2012-08-22 13:30:19 <gavinandresen> ... so I'd like to make that harder to do.
385 2012-08-22 13:30:39 <BlueMatt> meh, wallets should be aware of the issue
386 2012-08-22 13:30:55 <jgarzik> sipa: (1) yep, you're right, message checksum is at the front. (2) yes, you send the message header with MSG_MORE, to tell the kernel to _not_ flush the header out of the buffer. then you use sendfile(2).
387 2012-08-22 13:31:05 <jgarzik> gavinandresen: 0.7 rc1 today?
388 2012-08-22 13:31:08 <gavinandresen> it just 'feels' like the kind of thing that could be leveraged with something else into an attack.
389 2012-08-22 13:31:20 <sipa> BlueMatt: i think it's quite important to fix, maybe not for now
390 2012-08-22 13:31:40 <BlueMatt> eventually...sure, but its not excruciatingly high priority
391 2012-08-22 13:31:40 <sipa> but any scheme that relies on sending signed messages directly to a receiver would easily break if people can do this
392 2012-08-22 13:31:42 <gavinandresen> jgarzik: I won't have time to spin mac binaries before I head out today (but I'll be back tomorrow)
393 2012-08-22 13:32:02 <sipa> s/signed messages/signed transactions/
394 2012-08-22 13:36:23 <eb3fu> can a script force an input's script to be the same or access it somehow to compare
395 2012-08-22 13:36:39 <eb3fu> through any tricky mechanism?
396 2012-08-22 13:36:46 <BlueMatt> not directly
397 2012-08-22 13:36:48 <sipa> it can only access the stack which is left by the input script
398 2012-08-22 13:37:21 <BlueMatt> (well, ignoring p2sh)
399 2012-08-22 13:37:35 <eb3fu> is there any technical reason why a script shouldn't be able to access the input script
400 2012-08-22 13:38:09 <eb3fu> i was thinking it would be useful for creating a blockchain based security which could be split and exchanged, if you received it you would know that all of the previous inputs were the same, and that they were all derived from one transaction
401 2012-08-22 13:43:28 <sipa> how about this: we add a boolen flag to EvalScript "fStrictEncodings", which, if true, does not accept non-canonical signatures or public keys
402 2012-08-22 13:44:37 <sipa> which is for now only enabled for the memory pool
403 2012-08-22 13:45:39 <jgarzik> sipa: ACK
404 2012-08-22 13:46:06 <sipa> you need a bit more for also checking send-to-pubkey outputs, but that's it
405 2012-08-22 13:46:14 <sipa> oh, and maybe multisig things
406 2012-08-22 14:02:27 <CodeLion> Hey I asked this question yesterday but forgot to bookmark the link I was given. Where can I learn about the non-network bitcoin functions such as generating an address? And also where can I learn about the network related ones, such as sending and recieving coins? I ask it as 2 questions because either will be good to get me starte while I await the next
407 2012-08-22 14:03:25 <BlueMatt> en.bitcoin.it
408 2012-08-22 14:06:23 <CodeLion> BlueMatt ^_^ I know, could you supply the more specific page please? My disorder makes it difficult to find stuff. Especially when I might have to crawl 3 or 4 pages before I find the right one....
409 2012-08-22 14:07:02 <BlueMatt> https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) <-- local api
410 2012-08-22 14:07:38 <BlueMatt> https://en.bitcoin.it/wiki/Protocol_Specification <-- p2p net spec
411 2012-08-22 14:11:54 <CodeLion> Thanks bluematt
412 2012-08-22 14:12:06 <CodeLion> Let me look through those and see if they cover everything
413 2012-08-22 14:12:55 <CodeLion> JSON eh? w00t that should be easy
414 2012-08-22 14:13:46 <CodeLion> Wait that looks like interacting with a local server? Can anyone clarify?
415 2012-08-22 14:15:52 <lianj> CodeLion: yes
416 2012-08-22 14:17:29 <CodeLion> Lianj: hmm. I'm trying to write a program in python, at the moment I am implementing a function to generate a new bitcoin privatekey/address pair.
417 2012-08-22 14:17:41 <CodeLion> I would assume you don't need networking for that, right?
418 2012-08-22 14:18:07 <CodeLion> Or does there have to be an instance of this "server" mentioned running on wherever you are running the python?
419 2012-08-22 14:18:35 <lianj> right, you can just use some pure python lib that does it already
420 2012-08-22 14:20:30 <CodeLion> hm
421 2012-08-22 14:20:38 <CodeLion> There isn't a wiki page about it?
422 2012-08-22 14:20:50 <CodeLion> I was going to write it myself, thats half the fun
423 2012-08-22 14:21:49 <lianj> https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
424 2012-08-22 14:21:54 <lianj> train your google-fu ;)
425 2012-08-22 14:23:05 <CodeLion> Lianj: I try, but I quickly forget names and identifiers on stuff I read... god how to explain this? Give me a moment, what I just said it utterly inadequet
426 2012-08-22 14:24:33 <CodeLion> For example: suppose I read: "Cat: a four legged animal with hair. Often domesticated, likes fish." On a webpage, then follow a link to a different, related piece of info. I will remember the deffinition but not the name. So I remember 4 legs etc, but not the word "cat"
427 2012-08-22 14:24:43 <CodeLion> So when I try to find stuff online,
428 2012-08-22 14:24:51 <CodeLion> I lose track of stuff quickly
429 2012-08-22 14:25:03 <CodeLion> do you follow that at all?
430 2012-08-22 14:25:51 <CodeLion> However thank you very much for the 3rd link
431 2012-08-22 14:26:01 <CodeLion> I'll go to work on my code now. :D
432 2012-08-22 14:26:04 <gmaxwell> sipa: I'm not being too much of a dick on that marker address thread, am I?
433 2012-08-22 14:27:33 <lianj> btw thats a damn ugly ruby example on https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
434 2012-08-22 14:30:14 <BlueMatt> lianj: its a wiki, fix it ;)
435 2012-08-22 14:46:38 <lianj> BlueMatt: no account, can you edit it please? https://pastee.org/fv2pm
436 2012-08-22 14:58:35 <lianj> BlueMatt: or better this version: https://pastee.org/ct88s (uses only stdlib, so no extra gem/lib to install)
437 2012-08-22 15:02:48 <jgarzik> come on, mainnet
438 2012-08-22 15:02:50 <jgarzik> orphan, damn you
439 2012-08-22 15:02:56 <jgarzik> I want to test my reorg code
440 2012-08-22 15:03:11 <jgarzik> maybe I should switch to testnet3 and enlist gmaxwell's help
441 2012-08-22 15:03:18 <luke-jr_> jgarzik: find a miner vuln to CVE-2012-2459 ;p
442 2012-08-22 15:12:13 <jgarzik> I really should compare pynode's merkle code to bitcoin and bitcoinj's code
443 2012-08-22 15:12:33 <jgarzik> https://github.com/jgarzik/pynode/blob/master/bitcoin/core.py#L263
444 2012-08-22 15:14:44 <sipa> gmaxwell: i expected you to react :p
445 2012-08-22 15:16:22 <phantomcircuit> i sort of wonder about the use of RIPEMD160
446 2012-08-22 15:16:38 <lianj> jgarzik: isnt something like `return nil if tx != tx.uniq` at the top enough?
447 2012-08-22 15:16:43 <phantomcircuit> it's not nearly as well understood as the other cryptographic primitives used in the protocol
448 2012-08-22 15:17:30 <jgarzik> phantomcircuit: use of RIPEMD160 where specifically? address, script or other?
449 2012-08-22 15:17:39 <phantomcircuit> address
450 2012-08-22 15:17:57 <phantomcircuit> there are so many layers of sha256 i doubt it's really an issue
451 2012-08-22 15:18:04 <phantomcircuit> but it just seems odd
452 2012-08-22 15:23:28 <jgarzik> ACTION ponders prediction markets, and forgiveness vs. permission