1 2012-01-23 00:00:23 <gmaxwell> pong
2 2012-01-23 00:00:37 <roconnor> gmaxwell: can you mine testnet for a few seconds?
3 2012-01-23 00:00:41 <gmaxwell> sure.
4 2012-01-23 00:00:53 <gmaxwell> is there a txn I should check my memory pool for first?
5 2012-01-23 00:01:15 <roconnor> yes, but I don't know how to identify it, by address sent to?
6 2012-01-23 00:01:40 <gmaxwell> roconnor: if you look at list transactions or your logs you should be able to tell me the txn id?
7 2012-01-23 00:01:48 <roconnor> my logs?
8 2012-01-23 00:02:17 <sipa> ~/.bitcoin/testnet/debug.log
9 2012-01-23 00:02:22 <sipa> if you use the satoshi client
10 2012-01-23 00:02:58 <roconnor> oh, that's where all that stuff goes
11 2012-01-23 00:04:47 <gmaxwell> roconnor: well, while you're looking I did one block.
12 2012-01-23 00:05:26 <roconnor> ah that worked
13 2012-01-23 00:29:58 <midnightmagic> gmaxwell: In retrospect, I wanted it to be clear that payout was 1 satoshi less, so I'm glad it worked out that way. There's a clear 49.9999999.. which is easy for a newb to see and go "huh.."
14 2012-01-23 00:30:43 <gmaxwell> midnightmagic: yes, would have been better if you'd just not included those transactions.
15 2012-01-23 00:31:06 <gmaxwell> As a result, if you count up the exiting bitcoin minus the lost you get a pretty weird number.
16 2012-01-23 00:32:23 <gmaxwell> Diablo-D3: sin is periodic and continious, you'll be counting for a long time.
17 2012-01-23 00:32:35 <Diablo-D3> gmaxwell: argh!
18 2012-01-23 00:32:38 <sipa> LOL
19 2012-01-23 00:33:04 <midnightmagic> Sin is an illusion anyway, so let someone count up my invisible ambiguous naughties.
20 2012-01-23 00:33:23 <gmaxwell> Enough tangents.
21 2012-01-23 00:33:54 <sipa> i cosi{gn,ne} that
22 2012-01-23 00:34:27 <midnightmagic> second
23 2012-01-23 00:34:57 <Diablo-D3> midnightmagic: no one cares about your ambiguous naughties.
24 2012-01-23 00:35:03 <sipa> midnightmagic: nice one :)
25 2012-01-23 00:38:38 <midnightmagic> Diablo-D3: ???_??? second i said!
26 2012-01-23 00:39:20 <Diablo-D3> I wish I knew what the fuck that was supposed to be
27 2012-01-23 01:10:23 <roconnor> putting the signature for the transaction inside the pubScript is very difficult and possible infeasible.
28 2012-01-23 01:12:00 <luke-jr> ?
29 2012-01-23 01:13:02 <roconnor> I want to test the signature removeing part of signature verification
30 2012-01-23 01:33:15 <Mad7Scientist> bitcoin is sitting here crashed it crashing from me attaching gdb what do I do
31 2012-01-23 01:33:39 <gmaxwell> gdb just freezes it.. if you detach it should continue.
32 2012-01-23 01:33:59 <Mad7Scientist> some threads became status "t" in htop
33 2012-01-23 01:34:14 <Mad7Scientist> it crashed SIGSEGV
34 2012-01-23 01:34:25 <Mad7Scientist> gmaxwell, http://dpaste.com/691863/
35 2012-01-23 01:34:30 <Mad7Scientist> http://dpaste.com/691864/
36 2012-01-23 01:37:25 <Mad7Scientist> well :/ is it worth investigating the crash
37 2012-01-23 01:47:37 <Mad7Scientist> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
38 2012-01-23 01:47:38 <gribble> Error: "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!" is not a valid command.
39 2012-01-23 01:51:25 <Mad7Scientist> no support?
40 2012-01-23 01:51:33 <Mad7Scientist> :(
41 2012-01-23 02:05:45 <BlueMatt> Mad7Scientist: those are the most useless backtraces ever...
42 2012-01-23 02:05:52 <BlueMatt> what version? os? bitcoin-qt or d?
43 2012-01-23 02:12:56 <gmaxwell> I'm happy to have produced a P2SH supporting block now: https://blockexplorer.com/rawblock/0000000000000ac720f9373d1dcd00ad353c79ff49908a930b42681bbd92e1cd
44 2012-01-23 02:13:17 <gmaxwell> Gavin, Thanks for merging forestv's getmemorypool patch. :)
45 2012-01-23 02:14:40 <Mad7Scientist> BlueMatt, Linux QT 0.5.2
46 2012-01-23 02:14:50 <Mad7Scientist> I thought a crash was worth looking in to
47 2012-01-23 02:14:58 <Mad7Scientist> I don't really know what I'm doing
48 2012-01-23 02:15:13 <Mad7Scientist> I started this because of the I/Q on ~/.bitcoin/ freeze up problem
49 2012-01-23 02:15:18 <gmaxwell> Mad7Scientist: how did you invoke gdb?
50 2012-01-23 02:15:20 <unicron> is there a list of which way pools are voting?
51 2012-01-23 02:15:23 <gmaxwell> did you give it the path to the binary?
52 2012-01-23 02:15:25 <Mad7Scientist> I/O
53 2012-01-23 02:15:36 <Mad7Scientist> no I didn't I just did attach <PID>
54 2012-01-23 02:15:46 <gmaxwell> ah, thats why you didn't get any symbol names.
55 2012-01-23 02:16:04 <gmaxwell> you need to do gdb /path/to/bitcoin/bitcoin -p <PID>
56 2012-01-23 02:16:19 <Mad7Scientist> I geuss it's the file command
57 2012-01-23 02:16:24 <Mad7Scientist> (once gdb is opened)
58 2012-01-23 02:16:28 <gmaxwell> sadly that output is useless. I've tried attaching gdb several times now, and it doesn't crash it here.
59 2012-01-23 02:16:52 <Mad7Scientist> I was stopping and starting it in gdb then it just crashed
60 2012-01-23 02:17:20 <lianj> gmaxwell: the first output of the first tx?
61 2012-01-23 02:17:24 <gmaxwell> symbol-file IIRC. maybe it's just file.
62 2012-01-23 02:17:34 <Mad7Scientist> Is there a way to load the file while gdb is still open?
63 2012-01-23 02:17:38 <gmaxwell> lianj: no the p2sh vote is in the coinbase.
64 2012-01-23 02:17:46 <lianj> oh ok :D
65 2012-01-23 02:17:52 <gmaxwell> Mad7Scientist: symbol-file I think.
66 2012-01-23 02:18:05 <Mad7Scientist> yeah
67 2012-01-23 02:18:48 <lianj> is there a p2sh tx on blockexplorer yet?
68 2012-01-23 02:19:04 <Mad7Scientist> (gdb) symbol-file /home/rep/stuff/prg/bitcoin-0.5.2-linux/bin/32/bitcoin-qt
69 2012-01-23 02:19:13 <Mad7Scientist> Reading symbols from /home/rep/stuff/prg/bitcoin-0.5.2-linux/bin/32/bitcoin-qt...(no debugging symbols found)...done.
70 2012-01-23 02:20:34 <gmaxwell> lianj: no, because p2sh supporting miners are not mining them currently.
71 2012-01-23 02:20:54 <gmaxwell> (only failing to mine invalid ones)
72 2012-01-23 02:21:18 <gmaxwell> BlueMatt: are we really distributing stripped binaries that sucks. Do you have an unstripped one we can use for symbols?
73 2012-01-23 02:21:36 <lianj> hm, but i want a tx as fixture for my tests ^^ thanks anw
74 2012-01-23 02:23:09 <Mad7Scientist> I want to compile bitcoin
75 2012-01-23 02:23:20 <Mad7Scientist> I tryped qmake and that was not correct
76 2012-01-23 02:23:22 <Mad7Scientist> I am on Gentoo
77 2012-01-23 02:24:07 <gmaxwell> Mad7Scientist: see the readme file.
78 2012-01-23 02:25:10 <Mad7Scientist> So I should use Qt creator?
79 2012-01-23 02:26:43 <Mad7Scientist> the readme file just says run qmake
80 2012-01-23 02:26:52 <Mad7Scientist> without any arguments
81 2012-01-23 02:27:28 <gmaxwell> it .. what?
82 2012-01-23 02:28:05 <Mad7Scientist> prints the help as many programs do
83 2012-01-23 02:28:17 <Mad7Scientist> when run without any arguments
84 2012-01-23 02:29:18 <Mad7Scientist> Ahh I was in the src/src directory
85 2012-01-23 02:31:12 <dwon> Hmm. There's no v0.5.2 tag at https://github.com/bitcoin/bitcoin
86 2012-01-23 02:31:34 <gmaxwell> dwon: correct, it's in the stable repository.
87 2012-01-23 02:32:29 <Mad7Scientist> db_cxx.h not found. I assume the path to /usr/include/db4.x/ has to be added somewhere
88 2012-01-23 02:33:13 <gmaxwell> On gentoo, yes.
89 2012-01-23 02:33:19 <Mad7Scientist> I have 6 versions of db installed
90 2012-01-23 02:33:30 <gmaxwell> yes, because you run gentoo.
91 2012-01-23 02:33:32 <dwon> gmaxwell: What "stable repository"? I went to http://bitcoin.org/, I clicked "get the source code", and cloned that. And there's a v0.5.1 tag there.
92 2012-01-23 02:33:40 <Mad7Scientist> But I don't know which version I should use
93 2012-01-23 02:33:55 <Mad7Scientist> is it the 4x series?
94 2012-01-23 02:34:37 <gmaxwell> dwon: https://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable the forks for minor revisions on old versions are there.
95 2012-01-23 02:34:38 <Mad7Scientist> ok for debian it says db-4.8 ...
96 2012-01-23 02:35:08 <gmaxwell> Mad7Scientist: just not 5.x so long as you want compatiblity with the binaries.
97 2012-01-23 02:35:20 <dwon> gmaxwell: That's really, really confusing.
98 2012-01-23 02:38:16 <CIA-76> DiabloMiner: Patrick McFarland master * rd85b1ba / (2 files in 2 dirs): Shorten debug status line, fix kernel for layered vectors - http://git.io/pv0idA https://github.com/Diablo-D3/DiabloMiner/commit/d85b1ba456c4a1c75c760075cf1c0f325eb818c1
99 2012-01-23 02:41:02 <Mad7Scientist> oh heck
100 2012-01-23 02:41:25 <Mad7Scientist> it appears the Makefile that qmake made does not specify any optimizations in CFLAGS
101 2012-01-23 02:41:40 <gmaxwell> Hm?
102 2012-01-23 02:41:53 <gmaxwell> are you sure you're not just looking at the linker line?
103 2012-01-23 02:43:04 <BlueMatt> gmaxwell: yea, unstripped binaries are something like 50M iirc
104 2012-01-23 02:43:07 <Mad7Scientist> I did source /etc/make.conf to set CFLAGS
105 2012-01-23 02:43:19 <Mad7Scientist> deleted the Makefile
106 2012-01-23 02:43:20 <BlueMatt> and no, there are no unstripped releases afaik (though I usually use them when Im debugging)
107 2012-01-23 02:43:21 <Mad7Scientist> ran qmake
108 2012-01-23 02:43:30 <Mad7Scientist> looked at the makefile. No optimizations.
109 2012-01-23 02:43:54 <gmaxwell> BlueMatt: they should be posted too as part of the build process.
110 2012-01-23 02:44:03 <BlueMatt> should be
111 2012-01-23 02:44:32 <BlueMatt> is there no way to build a map of offset -> function that can be examined afterwards?
112 2012-01-23 02:44:49 <BlueMatt> s/no way/no easy way/
113 2012-01-23 02:45:06 <gmaxwell> yes, using objcopy.
114 2012-01-23 02:45:10 <Mad7Scientist> I see all the defines at the top of the Makefile. Can I edit one line that will change both CFLAGS and CXXFLAGS ?
115 2012-01-23 02:45:37 <gmaxwell> BlueMatt: http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target
116 2012-01-23 02:45:42 <Mad7Scientist> neverminde I see it includes $(DEFINES)
117 2012-01-23 02:46:09 <BlueMatt> gmaxwell: nice, Ill look into getting it into 0.6
118 2012-01-23 02:56:20 <roconnor> etotheipi_: ping
119 2012-01-23 02:56:35 <etotheipi_> roconnor, ack
120 2012-01-23 02:56:45 <etotheipi_> err... how do I respond to ping?
121 2012-01-23 02:56:53 <gmaxwell> ICMP ECHO REPLY
122 2012-01-23 02:56:59 <roconnor> RST
123 2012-01-23 02:57:13 <roconnor> etotheipi_: ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
124 2012-01-23 02:57:23 <roconnor> what is base58Txid and varIntTxSize
125 2012-01-23 02:57:39 <gmaxwell> BlueMatt: does that qmake crap manage to make a binary without stack protector enabled and other useful paranoid?
126 2012-01-23 02:58:02 <etotheipi_> the transaction that has all the txIn scripts replaced with the txOut scripts of the prev txs... hash that
127 2012-01-23 02:58:13 <etotheipi_> so it's a transaction ID, but of a modified tx
128 2012-01-23 02:58:25 <roconnor> your example has a very short hash
129 2012-01-23 02:58:32 <BlueMatt> gmaxwell: how would I know?
130 2012-01-23 02:58:33 <etotheipi_> since you don't have sigs yet, you can't determine the real Tx ID
131 2012-01-23 02:58:39 <etotheipi_> oh yeah, sorry.. it's truncated
132 2012-01-23 02:58:52 <etotheipi_> 8 bytes, I believe
133 2012-01-23 02:59:11 <gmaxwell> BlueMatt: you were the only person obviously around that has been building binaries for other people to use?
134 2012-01-23 02:59:11 <roconnor> etotheipi_: if you get some time this week, I'd would be nice to fully specify your format in BIP 0010
135 2012-01-23 02:59:15 <BlueMatt> gmaxwell: I see no mentions of stack protector in the g++ calls from qmake?
136 2012-01-23 02:59:22 <BlueMatt> s/?//
137 2012-01-23 02:59:23 <etotheipi_> and it's base58 to distinguish it from a real Tx ID which is usually in hex
138 2012-01-23 02:59:31 <gmaxwell> BlueMatt: bleh!
139 2012-01-23 02:59:34 <BlueMatt> gmaxwell: so Id assume it has those things disabled...
140 2012-01-23 02:59:38 <etotheipi_> roconnor, I'd like to iron out BIP 0010...
141 2012-01-23 02:59:44 <BlueMatt> (or default, which, on ubuntu, is enabled iirc)
142 2012-01-23 02:59:51 <BlueMatt> not sure about mingw
143 2012-01-23 02:59:52 <etotheipi_> so I'd be happy to work on it with you
144 2012-01-23 02:59:56 <gmaxwell> BlueMatt: yea, it's enabled on ubuntu, nowhere else.
145 2012-01-23 02:59:57 <roconnor> oh okay
146 2012-01-23 03:00:11 <etotheipi_> roconnor, something to think about
147 2012-01-23 03:00:13 <BlueMatt> gmaxwell: its all built on ubuntu, question is does the mingw ubuntu g++ enable it or not
148 2012-01-23 03:00:20 <gmaxwell> etotheipi_: I'll happly look at what you do there and yell at you about it!
149 2012-01-23 03:00:25 <etotheipi_> I don't know if it goes in a separate BIP, but I think it needs to go in a bip
150 2012-01-23 03:00:25 <gmaxwell> BlueMatt: hmmmmm!
151 2012-01-23 03:00:37 <etotheipi_> gmaxwell, I know you will! I don't need to invite you to know that :)
152 2012-01-23 03:00:41 <gmaxwell> BlueMatt: I could tell from looking at the binary .. but meh.
153 2012-01-23 03:01:01 <etotheipi_> roconnor, here's my thought about expanding BIP 10
154 2012-01-23 03:01:25 <etotheipi_> BIP 0010 is about assisting with the SPENDING of a multi-sig TxOut
155 2012-01-23 03:01:34 <BlueMatt> gmaxwell: the hardening stuff is also only in the mingw makefile
156 2012-01-23 03:01:42 <BlueMatt> s/mingw/unix/
157 2012-01-23 03:01:57 <BlueMatt> so its not on in win32 bitcoind either
158 2012-01-23 03:02:14 <etotheipi_> roconnor, but if you are talking about a buyer-seller contract, with buyer and seller each putting up 10-20% of purchase price as a kind of "deposit" on the tx... then there needs to be a way for both parties to buy into the exact same tx
159 2012-01-23 03:02:14 <gmaxwell> hmph. It doesn't work on some platforms, but I'm pretty sure it works on mingw32.
160 2012-01-23 03:02:55 <etotheipi_> you can't send the tx separately, what if one person sends their money to the 2-of-2 address, then the other one backs out and/or disappears
161 2012-01-23 03:03:23 <Runnigan> Hi, I keep getting this error when trying to do bitcoind commands:
162 2012-01-23 03:03:27 <etotheipi_> but that means that one person needs to be able to prepare such a contract
163 2012-01-23 03:03:34 <BlueMatt> gmaxwell: essentially if you want a secure bitcoin environment, go use bitcoind on linux
164 2012-01-23 03:03:39 <Runnigan> error: You must set rpcpassword=<password> in the configuration file: /root/.bitcoin/bitcoin.conf
165 2012-01-23 03:04:03 <Runnigan> I've set the rpcpassword though, so don't know what I'm missing
166 2012-01-23 03:04:12 <etotheipi_> roconnor, BIP 0010 allows just as easily as spending a multi-sig tx, the capability to collect signatures for such a contract-entry transaction
167 2012-01-23 03:04:16 <gmaxwell> BlueMatt: sure sure. But the security paranoia crap isn't for the the user, it's for everything else. Because if a lot of windows bitcoin users get 0wned up then thats bad for all bitcoin users.
168 2012-01-23 03:04:20 <BlueMatt> gmaxwell: if you feel like looking them up, please do and add them to the relevant makefiles...
169 2012-01-23 03:04:21 <TuxBlackEdo> Runnigan, you are running this in root?
170 2012-01-23 03:04:32 <gmaxwell> BlueMatt: yea, I'll figured it out. Thanks for giving it a look.
171 2012-01-23 03:04:43 <etotheipi_> but one person still has to prepare it, which means they need to get an address from the other person, and a change address too, so they know how to prepare outputs
172 2012-01-23 03:04:56 <TuxBlackEdo> Runnigan, try "nano -w ~/.bitcoin/bitcoin.conf"
173 2012-01-23 03:05:07 <TuxBlackEdo> instead of /root/.bitcoin/bitcoin.conf
174 2012-01-23 03:05:34 <etotheipi_> so that was a verbose way of saying... might want to add some kind of address exchange to BIP 0010 to help with the *creation* of multi-sig contracts, not just spending
175 2012-01-23 03:05:41 <Runnigan> ok..
176 2012-01-23 03:06:13 <TuxBlackEdo> Runnigan, or you can try ./bitcoind --rpcpassword=test
177 2012-01-23 03:06:52 <Runnigan> ok just did it
178 2012-01-23 03:06:58 <TuxBlackEdo> worked?
179 2012-01-23 03:07:15 <Runnigan> I got this
180 2012-01-23 03:07:17 <Runnigan> "Warning: To use bitcoind, you must set rpcpassword=<password> in the configuration file: /root/.bitcoin/bitcoin.conf If the file does not exist, create it with owner-readable-only file permissions."
181 2012-01-23 03:07:34 <etotheipi_> roconnor, did that make sense?
182 2012-01-23 03:07:56 <TuxBlackEdo> Runnigan, chmod 700 /root/.bitcoin/bitcoin.conf
183 2012-01-23 03:08:22 <TuxBlackEdo> i mean
184 2012-01-23 03:08:26 <TuxBlackEdo> Runnigan, chmod 400 /root/.bitcoin/bitcoin.conf
185 2012-01-23 03:08:34 <etotheipi_> although... maybe this is solved with using alternate hashcodes...
186 2012-01-23 03:08:54 <roconnor> etotheipi_: yes
187 2012-01-23 03:09:21 <roconnor> like in https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts
188 2012-01-23 03:09:55 <Runnigan> I got: "chmod: cannot access `/root/.bitcoin/bitcoin.conf': No such file or directory "
189 2012-01-23 03:10:41 <TuxBlackEdo> Runnigan, echo "rpcpassword=test">/root/.bitcoin/bitcoin.conf
190 2012-01-23 03:11:10 <etotheipi_> roconnor, are the other hashcodes disabled?
191 2012-01-23 03:11:18 <josephcp> (after you get it running, you probably shouldn't be running services as root...)
192 2012-01-23 03:11:37 <Runnigan> ok did it
193 2012-01-23 03:12:07 <etotheipi_> if the other hashcodes are not accepted in the network, then a temp solution will be needed
194 2012-01-23 03:12:52 <Runnigan> some progress, I got a new error: "error: couldn't connect to server"
195 2012-01-23 03:13:33 <josephcp> did you first stop all existing bitcoin daemons, then re-run "bitcoind -daemon"?
196 2012-01-23 03:13:34 <Runnigan> so I assume I have to start the daemon
197 2012-01-23 03:13:53 <Runnigan> no I didn't
198 2012-01-23 03:13:55 <josephcp> actually just run "bitcoind" first and then open a new terminal window
199 2012-01-23 03:14:08 <josephcp> and type bitcoind --rpcpassword=test getinfo"
200 2012-01-23 03:14:20 <josephcp> err "bitcoind --rpcpassword=test getinfo" in the new terminal window
201 2012-01-23 03:14:30 <TuxBlackEdo> you dont need the " --rpcpassword=test"
202 2012-01-23 03:14:34 <TuxBlackEdo> yes josephcp
203 2012-01-23 03:14:36 <josephcp> oh right
204 2012-01-23 03:14:39 <josephcp> localhost
205 2012-01-23 03:15:04 <TuxBlackEdo> you should be able to just do: bitcoind getinfo
206 2012-01-23 03:17:25 <TuxBlackEdo> josephcp, you can run bitcoind in a screen session if you got the screen package installed: screen -dmS wallet bitcoind
207 2012-01-23 03:17:55 <josephcp> yeah i love screen ;-)
208 2012-01-23 03:18:14 <josephcp> but i usually run it in a daemon because i juggle too many screen sessions as is haha
209 2012-01-23 03:34:09 <etotheipi_> do non-standard hashcodes cause validation failure right now?
210 2012-01-23 03:34:33 <etotheipi_> or are they treated like non-std tx: if they appear in the blockchain they're alright, but no one will relay/mine them
211 2012-01-23 03:34:40 <etotheipi_> ?
212 2012-01-23 03:36:32 <josephcp> do you mean opcode?
213 2012-01-23 03:36:48 <etotheipi_> no, using something other than SIGHASH_ALL
214 2012-01-23 03:36:48 <josephcp> because i wanted to check that sometime too
215 2012-01-23 03:37:12 <josephcp> ooooh
216 2012-01-23 03:37:50 <josephcp> i don't remember any sort of restriction on it when i was going through the code but i can't say for sure
217 2012-01-23 03:38:47 <etotheipi_> well, the multi-sig stuff I'm looking at right now would get dramatically simpler with these alternate hashcodes... I'm wondering if they are usable, or will be any time soon
218 2012-01-23 03:41:12 <josephcp> i'm not sure exactly what you're thinking about w.r.t sighash codes, but i know when i've thought about alternate uses of sighash, remainder coins are sometimes a stumbling block for me
219 2012-01-23 03:41:53 <josephcp> splitting them and such i mean, is this for BIP_0010?
220 2012-01-23 03:42:31 <etotheipi_> more generally, it is for *creation* of multisig transactions that require inputs from multiple parties
221 2012-01-23 03:43:08 <etotheipi_> but since BIP 0010 proposes how to *spend* multi-sig tx's, it's probably appropriate to include the creation side, too
222 2012-01-23 03:43:47 <etotheipi_> it seems to me that the parties not creating the tx need to send the exact coinage to a new address to be used for this purpose
223 2012-01-23 03:44:39 <etotheipi_> so if I need to contribute 1.284 BTC to this tx but someone else is preparing the tx and doesn't always want to have to get a change address for me... I just 1.284 BTC to a new address, and then give them that address to use as the input
224 2012-01-23 03:44:41 <josephcp> yeah, exactly remainder coins are tricky ;-)
225 2012-01-23 03:45:26 <josephcp> and since sighash is for the entire transaction from what i understand, you can't have sighash_anyone can pay for one output and sighash_single for another or whatever
226 2012-01-23 03:45:44 <etotheipi_> it adds an extra tx to the network... and actually, if thye are sending the address they might as well send a change address too
227 2012-01-23 03:46:10 <etotheipi_> you can't have different sighashes for the outputs, but you can for the inputs
228 2012-01-23 03:46:22 <josephcp> yeah, this is why i think having really long escrowed addresses for now is a good solution and we can call it a day :-P
229 2012-01-23 03:46:36 <josephcp> oh really?
230 2012-01-23 03:46:44 <etotheipi_> well that's what I want to address in BIP 0010
231 2012-01-23 03:47:15 <etotheipi_> josephcp, I'm fairly confident that's true... but what do I know ? :)
232 2012-01-23 03:47:34 <etotheipi_> it's certainly, semantically possible
233 2012-01-23 03:47:41 <josephcp> haha, well i'll defer to you on that, i haven't spent enough time on the code
234 2012-01-23 03:48:07 <etotheipi_> the hashcode is part of the sig, and only identifies what parts of the tx were signed
235 2012-01-23 03:48:18 <josephcp> so question, i was going to spend some time on this later, but if someone already knows the answer, is deisabled opcodes still allowed if someone else signs the block or is the entire block rejected
236 2012-01-23 03:48:22 <josephcp> like OP_CAT
237 2012-01-23 03:48:24 <etotheipi_> so each sig could, strictly speaking, use a different hashcode.... but I don't know if the network would consider it valid
238 2012-01-23 03:48:55 <etotheipi_> disabled op-codes mean that the tx/block will be rejected
239 2012-01-23 03:49:22 <josephcp> so it'd require an explicit big-fat fork? lame.
240 2012-01-23 03:49:25 <etotheipi_> non-disabled simply means they can be valid if they appear in a block, but no standard client will relay or mine them
241 2012-01-23 03:49:38 <josephcp> oh, but it'd still be accepted if it's in a block?
242 2012-01-23 03:49:39 <CIA-76> DiabloMiner: Patrick McFarland master * r57bbcb8 / src/main/resources/DiabloMiner.cl : Fix up how loops are done - http://git.io/zo6dyw https://github.com/Diablo-D3/DiabloMiner/commit/57bbcb8762500d56f8be3d02661b94d142deb548
243 2012-01-23 03:49:43 <etotheipi_> *non-disabled-but-non-standard
244 2012-01-23 03:49:53 <etotheipi_> josephcp, that's correct
245 2012-01-23 03:50:02 <etotheipi_> apparently Eligius pool will mine non-std tx for people
246 2012-01-23 03:50:17 <etotheipi_> you can prepare such a tx, and you can send it to Eligius to mine it for you
247 2012-01-23 03:50:50 <josephcp> yeah i know that's the case for non-standard transactions, but i wasn't sure if it was the case as well for disabled opcodes
248 2012-01-23 03:51:20 <etotheipi_> although that begs the question: you create a non-std TxOut script... which will usually require a non-std TxIn script... will that non-std Tx be propagated? or do you have to send that to Eligius, too?
249 2012-01-23 03:52:04 <etotheipi_> disabled op-codes really mean disabled... 99.99% of nodes out there will flat out reject any tx or block that uses those disabled codes
250 2012-01-23 03:52:12 <josephcp> i think non-standard txins are rejected by most, i don't know how eligius treats it
251 2012-01-23 03:52:14 <etotheipi_> it wouldn't even be a fork... .well it would be your personal little fork
252 2012-01-23 03:53:13 <josephcp> yeah that's what i thought about disabled opcodes :-(
253 2012-01-23 03:53:25 <josephcp> brb
254 2012-01-23 04:15:26 <Mad7Scientist> 260MB of resident memory to compile bitcoin is being used bi g++
255 2012-01-23 04:15:30 <Mad7Scientist> 400MB virt
256 2012-01-23 04:16:10 <gmaxwell> Mad7Scientist: yes, so? welcome to c++.
257 2012-01-23 04:16:25 <BlueMatt> wow thats pretty good, are you sure thats all youre using?
258 2012-01-23 04:16:47 <luke-jr> lol
259 2012-01-23 04:17:23 <luke-jr> in seriousness tho, that's because GCC never free()s
260 2012-01-23 04:17:36 <BlueMatt> really, never?
261 2012-01-23 04:17:44 <luke-jr> not by default, AFAIK
262 2012-01-23 04:17:52 <Mad7Scientist> jason_spirit_reader.cpp 460MB virt on g++
263 2012-01-23 04:17:53 <BlueMatt> damn
264 2012-01-23 04:18:01 <BlueMatt> Mad7Scientist: wait for main or rpc
265 2012-01-23 04:18:07 <luke-jr> try with --param ggc-min-expand=0 --param ggc-min-heapsize=32768
266 2012-01-23 04:18:17 <luke-jr> that will enable garbage collection
267 2012-01-23 04:18:18 <Mad7Scientist> oh crap
268 2012-01-23 04:18:27 <Mad7Scientist> Would gcc-2.95 use less memory?
269 2012-01-23 04:18:35 <luke-jr> Mad7Scientist: it probably wouldn't compile
270 2012-01-23 04:18:39 <luke-jr> try with --param ggc-min-expand=0 --param ggc-min-heapsize=32768
271 2012-01-23 04:18:46 <luke-jr> note that will make it slower ofc
272 2012-01-23 04:19:14 <Mad7Scientist> Is that because of bugs or lack of features in that older gcc
273 2012-01-23 04:19:18 <gmaxwell> Yes.
274 2012-01-23 04:19:19 <luke-jr> both
275 2012-01-23 04:19:36 <luke-jr> also, stuff compiled with GCC 2.95 won't run on any modern system
276 2012-01-23 04:19:38 <gmaxwell> Probably? Absolutely positively wouldn't, no probably about it.
277 2012-01-23 04:19:51 <Mad7Scientist> If the latter then is 2.95 not C99 compliant?
278 2012-01-23 04:20:06 <gmaxwell> Mad7Scientist: This is not C software this is C++ software.
279 2012-01-23 04:20:10 <luke-jr> Mad7Scientist: LOL
280 2012-01-23 04:20:17 <etotheipi_> gmaxwell, are alternate hashcodes "non-standard" or completely "disabled"?
281 2012-01-23 04:20:18 <luke-jr> Mad7Scientist: GCC 4.7 isn't C99 compliant yet
282 2012-01-23 04:20:18 <Mad7Scientist> oh that's right!
283 2012-01-23 04:20:34 <Mad7Scientist> I'm still thinking in the C only world
284 2012-01-23 04:20:48 <Mad7Scientist> lol is anything C99 compliant? This is like the web browser world
285 2012-01-23 04:21:00 <BlueMatt> gmaxwell: wait, whats up with new gccs?
286 2012-01-23 04:21:00 <Mad7Scientist> nothing is every fully compliant
287 2012-01-23 04:21:03 <BlueMatt> oh, old gccs
288 2012-01-23 04:21:03 <luke-jr> GCC is close enough IMO
289 2012-01-23 04:21:14 <luke-jr> BlueMatt: not just old, ancient
290 2012-01-23 04:21:24 <BlueMatt> yea
291 2012-01-23 04:21:31 <Mad7Scientist> I should add some swap over NFS to speed this up
292 2012-01-23 04:21:42 <luke-jr> &
293 2012-01-23 04:21:52 <luke-jr> distcc
294 2012-01-23 04:21:53 <josephcp> just add more ram or something
295 2012-01-23 04:21:57 <Mad7Scientist> would my 512MB ram and 1G swap be enough?
296 2012-01-23 04:22:03 <josephcp> ram is so cheap
297 2012-01-23 04:22:07 <luke-jr> Mad7Scientist: are you sane?
298 2012-01-23 04:22:09 <luke-jr> josephcp: not always
299 2012-01-23 04:22:18 <luke-jr> josephcp: sometimes, adding RAM is impossible
300 2012-01-23 04:22:49 <Mad7Scientist> I am not the kind that likes to have new hardware all the time
301 2012-01-23 04:22:54 <josephcp> yeah but in nearly all realistic cases in this situation :-P
302 2012-01-23 04:23:12 <etotheipi_> Mad7Scientist, you can get 16 GB of DDR3 RAM now for about $75
303 2012-01-23 04:23:24 <luke-jr> josephcp: not really
304 2012-01-23 04:23:26 <Mad7Scientist> I can hardly believe that
305 2012-01-23 04:23:41 <luke-jr> josephcp: my N900 will only ever have 256 MB RAM
306 2012-01-23 04:23:55 <Mad7Scientist> and Intel 815 512MB
307 2012-01-23 04:24:00 <josephcp> hence the caveat of "realistic cases in this situation" ;-)
308 2012-01-23 04:24:10 <luke-jr> josephcp: N900 is quite realistic
309 2012-01-23 04:24:20 <luke-jr> I probably need to upgrade bitcoind on it
310 2012-01-23 04:24:26 <etotheipi_> Mad7Scientist, http://www.newegg.com/Product/Product.aspx?Item=N82E16820226293
311 2012-01-23 04:24:30 <Mad7Scientist> It bohters me how software is so wasteful of system resources now
312 2012-01-23 04:24:36 <etotheipi_> I've seen deals go as low as $60
313 2012-01-23 04:24:56 <luke-jr> Mad7Scientist: me too, but what are you going to do? rewrite everything?
314 2012-01-23 04:24:58 <Mad7Scientist> (yet they still manage to make it work on embedded systems with 500MHz and 128MB of ram)
315 2012-01-23 04:25:02 <luke-jr> &
316 2012-01-23 04:25:11 <luke-jr> Mad7Scientist: you don't do much embedded development, do you?
317 2012-01-23 04:25:15 <josephcp> yeah but running full blow bitcoind on an N900 isn't a usual use case ;-)
318 2012-01-23 04:25:23 <Mad7Scientist> Just use old versions of software.
319 2012-01-23 04:25:26 <luke-jr> josephcp: ofc it is
320 2012-01-23 04:25:38 <josephcp> luke-jr: haha, then we can disagree on that ;-)
321 2012-01-23 04:25:38 <luke-jr> Mad7Scientist: are you asking for wrath?
322 2012-01-23 04:25:50 <Mad7Scientist> I don't do any embedded devolpment excetp for my lego toy (8 bit 16k ram)
323 2012-01-23 04:25:53 <luke-jr> josephcp: also, we're not talking about running, we're talking about compiling
324 2012-01-23 04:26:12 <luke-jr> Mad7Scientist: come back when you have a bitcoin client on it
325 2012-01-23 04:26:23 <josephcp> well you'd compile on that platform to run on that platform, oh well, i don't want to disagree with you about this, i think we're actually in agreement
326 2012-01-23 04:26:30 <luke-jr> :p
327 2012-01-23 04:26:54 <josephcp> hehehe
328 2012-01-23 04:27:15 <josephcp> with full blown QT!? O NOES
329 2012-01-23 04:27:21 <luke-jr> & of course
330 2012-01-23 04:27:26 <luke-jr> I run KDE 4.7
331 2012-01-23 04:27:54 <Mad7Scientist> QT is much more CPU friendly than gtk2 by like 5x it feels like
332 2012-01-23 04:27:55 <luke-jr> >>> Emerging (1 of 2) net-p2p/bitcoin-qt-0.5.2 from bitcoin
333 2012-01-23 04:28:14 <luke-jr> Portage is so slow on eMMC
334 2012-01-23 04:28:25 <josephcp> lol i bet
335 2012-01-23 04:28:27 <doublec> luke-jr: do you build on device?
336 2012-01-23 04:28:32 <luke-jr> doublec: yes
337 2012-01-23 04:28:37 <luke-jr> doublec: with distcc
338 2012-01-23 04:28:38 <luke-jr> <.<
339 2012-01-23 04:28:56 <doublec> luke-jr: are you using the default maemo OS on the device? Or another distro?
340 2012-01-23 04:29:02 <luke-jr> doublec: Gentoo
341 2012-01-23 04:29:13 <doublec> luke-jr: any links to getting gentoo running on it?
342 2012-01-23 04:29:19 <doublec> luke-jr: I have a N900 sitting doing nothing
343 2012-01-23 04:29:34 <luke-jr> the usual install steps mostly work, just add my n900 overlay :P
344 2012-01-23 04:48:21 <Mad7Scientist> It must have been like half hour since this 450MB virt thing and the CPU time on cc1plus is only 4 minutes
345 2012-01-23 04:48:23 <Mad7Scientist> swaplocked
346 2012-01-23 04:52:12 <gmaxwell> https://bitcointalk.org/index.php?topic=60229.0 < people are doing more completely stupid idiot things which attack bitcoin as a side effect.
347 2012-01-23 04:55:07 <cjdelisle> the scaling inadaquacy is not his fault
348 2012-01-23 04:55:28 <cjdelisle> and all this "attack" talk is distracting us from trying to fix the underlying problem IMO
349 2012-01-23 04:56:02 <gmaxwell> ...
350 2012-01-23 04:56:08 <gmaxwell> He's spouting gibberish cjdelisle
351 2012-01-23 04:57:44 <cjdelisle> you mean the post, I agree that it is not effective as a voting system but one of the great things about this world is we have the right to be wrong.
352 2012-01-23 04:59:16 <josephcp> oh god that was long. he's just converting strings into a bitcoin address
353 2012-01-23 04:59:27 <josephcp> that's his entire proposal
354 2012-01-23 04:59:47 <gmaxwell> cjdelisle: It's not just wrong, it's also full of technbabble gibberish, e.g. where he proposes to solve all problems via statistical Godel-like secure-but-not-perfect global Turing Machine
355 2012-01-23 05:00:13 <cjdelisle> yeap
356 2012-01-23 05:00:25 <gmaxwell> josephcp: yes, and it stops there. (1) Convert strings to addresses, (2) ???? (3) Mindmap quantum utopia.
357 2012-01-23 05:00:38 <cjdelisle> you don't have to like it or agree with it, it doesn't even have to be sane for you to be tollerant
358 2012-01-23 05:00:47 <josephcp> yeah lol, i thought i was missing something
359 2012-01-23 05:00:56 <gmaxwell> cjdelisle: I have a right to be intollerant of nonsense.
360 2012-01-23 05:02:07 <_W_> reality is that bitcoin is useful for a lot of tangential things, and people will take advantage of the network that is there for such issues that are unrelated to transfering value.
361 2012-01-23 05:02:17 <gmaxwell> cjdelisle: And we _do_ have effective anti-spamming remedies which are currently working quite well, but that doesn't mean that we don't have to be vigilant about stupid shit that would cause people to call for their removal.
362 2012-01-23 05:02:58 <gmaxwell> _W_: we have a system for doing most of those things which does not aversely impact bitcoin at all it's called merged mining.
363 2012-01-23 05:03:06 <_W_> the only thing you can do is make sure that any tangential thing also transfers value at least equivalent to the cost to the network
364 2012-01-23 05:03:09 <cjdelisle> I agree that there should be rules to prevent malicious spamming
365 2012-01-23 05:03:26 <_W_> gmaxwell, ah
366 2012-01-23 05:03:53 <cjdelisle> But if I want to log the state of my little dns tree once a week or once a day and I'm willing to pay for it, that should not be considered spam IMO.
367 2012-01-23 05:04:19 <gmaxwell> _W_: merged mining allows a miner to attach as much data as you want, via as many alternative systems as they want with O(1) cost (32 byte) to bitcoin.
368 2012-01-23 05:04:50 <gmaxwell> cjdelisle: yes, in fact it should be. Bitcoin is not data storage it's value transfer. I run a bitcoin node and your little DNS bullshit costs me disks space and computation.
369 2012-01-23 05:05:10 <CIA-76> bitcoin: Kano * ra1cd9defbaf2 cgminer/api.c: Return an error if using ADL API commands when it's not available http://tinyurl.com/6mhvj9c
370 2012-01-23 05:05:11 <CIA-76> bitcoin: Kano * r2e16d5e5439d cgminer/README: Add more explanation of JSON format and the 'save' command http://tinyurl.com/7hdgt5t
371 2012-01-23 05:05:13 <CIA-76> bitcoin: Con Kolivas * r7ac4b7806f3a cgminer/ (README api.c): Merge pull request #89 from kanoi/master http://tinyurl.com/83yttew
372 2012-01-23 05:05:19 <gmaxwell> I give freely of my disk space and computation in order to track the locations of all the bitcoins in order to trust the system, but that doesn't include using the system as a data dump.
373 2012-01-23 05:05:49 <gmaxwell> It's completely reasonable that the users of bitcoin can and will do whatever they can to keep the amount of data storage to a minimum.
374 2012-01-23 05:05:58 <josephcp> the only thing that might stop this is if an alt datadump blockchain was started though
375 2012-01-23 05:06:25 <josephcp> but it won't matter ultimiately because the quantity of data right now is too small to bother making one i guess
376 2012-01-23 05:07:09 <josephcp> i bet only like 2 or 3 people have used the "voting system"...
377 2012-01-23 05:07:17 <gmaxwell> josephcp: yea. Right now it's mostly a non-issue. My concern is primarly that this stuff doesn't gain popularity and they we'd have lots of users insisting to remove the anti DOS fee rules.
378 2012-01-23 05:07:18 <cjdelisle> I suppose it makes no difference that the same logging of "spam" transactions is what might root the unspent tx trees which will solve the scaling inadaquacy itself
379 2012-01-23 05:07:42 <josephcp> yeah, i understand. i think a reasonable tack to take is to encourage these people to use testnet for now?
380 2012-01-23 05:08:04 <gmaxwell> cjdelisle: all this spam stuff is creating additional unspendable txn, so in fact the proposed scaling improvements don't help in the face of it.
381 2012-01-23 05:08:19 <gmaxwell> josephcp: absolutely. And potentially namecoin for somethings.
382 2012-01-23 05:08:37 <gmaxwell> If they want to publish a unique key value pair.. thats what namecoin is for.
383 2012-01-23 05:09:13 <cjdelisle> I'm happy with the anti-DoS toll and I'm happy to pay it, what bothers me is the thought that someone might add heuristics to trap my transactions and drop them or worse "discourage" blocks which mine them.
384 2012-01-23 05:09:28 <josephcp> yeah good point namecoin would work a lot better for what he was doing
385 2012-01-23 05:09:46 <gmaxwell> cjdelisle: then you should also oppose spam too. Because the less spam, the more lose the heuristics can be.
386 2012-01-23 05:10:11 <josephcp> although it still doesn't take into account the many years of thought/papers that people put into an electronic voting system, verification risks etc
387 2012-01-23 05:10:35 <gmaxwell> josephcp: yea, POW blockchains are useless for voting. .. unless you want an election of computing power.
388 2012-01-23 05:10:44 <gmaxwell> If you want an election of people they don't help.
389 2012-01-23 05:11:40 <cjdelisle> I see bitcoin as primarily a notary system, anything that needs noterization can get it from the bitcoin swarm and the fact that bitcoin is the soverign currency for noterization is one thing that gives it real value.
390 2012-01-23 05:12:14 <josephcp> cjdelisle: the problem is that the cost of bitcoins transactions discounted to present value is below cost. 0.0005 bitcoins is a subsidized price
391 2012-01-23 05:12:36 <josephcp> if bitcoin gets big i mean
392 2012-01-23 05:12:40 <cjdelisle> hmm
393 2012-01-23 05:12:45 <gmaxwell> cjdelisle: the notary usage doesn't require any of this persistant storage stuff.
394 2012-01-23 05:13:17 <josephcp> and if you WANTED to do that you can create nonstandard transactions, i mean this is sortof the wrong way to go about it :-P
395 2012-01-23 05:13:41 <cjdelisle> I can trivially do it with standard transactions
396 2012-01-23 05:14:46 <cjdelisle> And we could say: ok guys, if you want something noterized, give the hash to this network and pay some bitcoin (smaller amount than a tx fee) and *one* tx will end up in the chain.
397 2012-01-23 05:15:21 <cjdelisle> but that is self defeating because the "pay some bitcoin" part adds just as much crap anyway
398 2012-01-23 05:15:36 <gmaxwell> cjdelisle: write a txn which is all fee, so it can be pruned and have the network give you back the tree fragment connecting it.
399 2012-01-23 05:16:07 <cjdelisle> I'm perfectly happy with that as a solution
400 2012-01-23 05:16:34 <cjdelisle> I've said all along, I want to tread softly but I don't want to get into alt-alt-currencies like MNC
401 2012-01-23 05:16:46 <gmaxwell> plus some little rpc call in bitcoin that takes the message and the seralized fragment and validates that its there.
402 2012-01-23 05:16:49 <josephcp> oh yeah good point, you can do sends of 0.00 bitcoins with fees right?
403 2012-01-23 05:16:57 <gmaxwell> Well there is no persistant storage assuming pruning.
404 2012-01-23 05:17:22 <cjdelisle> for me, this was never about bitcoinfs, I just need branch prevention
405 2012-01-23 05:17:43 <gmaxwell> Yea, if it doesn't require persistant storage then I don't give a shit.
406 2012-01-23 05:17:46 <josephcp> yeah but the block is signed with the txout it hink
407 2012-01-23 05:18:07 <gmaxwell> 0_o
408 2012-01-23 05:18:07 <josephcp> so it'd serve for some signature/notary purposes
409 2012-01-23 05:18:15 <gmaxwell> oh right sure.
410 2012-01-23 05:18:15 <josephcp> ?
411 2012-01-23 05:18:33 <gmaxwell> This would create an instantly prunable transaction.
412 2012-01-23 05:18:53 <josephcp> yeah so the db index of current bitcoins wouldn't have it at all
413 2012-01-23 05:19:30 <josephcp> it still would have network spam and block spam currently though :-P
414 2012-01-23 05:19:33 <gmaxwell> Well it would right now because we don't prune, but thats okay. It's just an improvement to prune those.
415 2012-01-23 05:19:37 <josephcp> but not as much of an evil i guess
416 2012-01-23 05:20:00 <cjdelisle> now is there a way that I can pay someone at random where the payer has no way to control who the payee is? paying the miner means miners can hold transactions until they strike a block and keep the change..
417 2012-01-23 05:20:00 <gmaxwell> josephcp: an acceptable cost to create something where there isn't persistant storage.
418 2012-01-23 05:20:20 <josephcp> yeah haha
419 2012-01-23 05:20:27 <gmaxwell> cjdelisle: I'm not following you there.
420 2012-01-23 05:20:48 <josephcp> cjdelisle: i'm writing code for that right now
421 2012-01-23 05:20:55 <gmaxwell> cjdelisle: you'd want to pay the miner it reduces the number of open transactions in the network when you do that.
422 2012-01-23 05:21:23 <josephcp> well it'd serve your purpose if i can surmise what you think...
423 2012-01-23 05:21:38 <cjdelisle> The only risk of paying the miner is the miner might make these transactions himself
424 2012-01-23 05:21:38 <josephcp> what exactly are you asking
425 2012-01-23 05:22:06 <gmaxwell> cjdelisle: ??????????????u???????????????????????????????????????
426 2012-01-23 05:22:19 <gmaxwell> (try again, but in sensible this time?)
427 2012-01-23 05:22:33 <nanotube> gmaxwell: that was "what are you talking about". quite readable :)
428 2012-01-23 05:22:50 <cjdelisle> suppose that for every domain you reg, it costs 100 times the average transaction fee in the last block, a miner could just create a transaction claiming a billion domains and paying himself.
429 2012-01-23 05:22:56 <gmaxwell> nanotube: ! you read greek!
430 2012-01-23 05:23:10 <josephcp> what
431 2012-01-23 05:23:20 <nanotube> heh so i do. i don't understand real greek though. but i can read greek-translit :)
432 2012-01-23 05:23:44 <gmaxwell> cjdelisle: yup. A notary is not a name registration system. Namecoin is what you want.
433 2012-01-23 05:24:31 <cjdelisle> I don't want anyone to have to buy namecoin to get domains.
434 2012-01-23 05:24:58 <josephcp> i'm still not following
435 2012-01-23 05:25:17 <josephcp> can you give a specific use case as an example?
436 2012-01-23 05:25:28 <gmaxwell> nanotube: I have some key on my keyboard mapped to 'modeswitch' and a mapping for all the keys to greek.
437 2012-01-23 05:25:36 <cjdelisle> the problem with namecoin is you have to buy it and then you have some on hand and then it's like a pyrimid scheme type thing
438 2012-01-23 05:25:48 <nanotube> cjdelisle: so you are thinknig of making a dns system built inside the bitcoin blockchain, rather than an altchain?
439 2012-01-23 05:25:56 <nanotube> something like http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal ?
440 2012-01-23 05:25:59 <josephcp> gmaxwell: oh wow i thought that was like a copy+paste :-P
441 2012-01-23 05:26:03 <gmaxwell> cjdelisle: you pay it back to the people running the namecoin network (the miners) so it's all closed loop.
442 2012-01-23 05:26:49 <cjdelisle> nanotube: no, I want to be as light on bitcoin as possible, I really don't want to fill the chain with crap.
443 2012-01-23 05:26:50 <nanotube> gmaxwell: hehe cute. so you type a lot of greek, then? :)
444 2012-01-23 05:27:18 <gmaxwell> nanotube: well, for math, you run out of letters pretty quickly...
445 2012-01-23 05:27:19 <nanotube> cjdelisle: well, then namecoin is your game ;) it couldn't be any lighter on bitcoin
446 2012-01-23 05:27:28 <nanotube> gmaxwell: ah heh ic
447 2012-01-23 05:27:36 <gmaxwell> Also stuff like this. !?????????'????`
448 2012-01-23 05:27:40 <cjdelisle> the reason I don't like namecoin is because it is a scam to make you invest
449 2012-01-23 05:27:52 <gmaxwell> cjdelisle: it's really not, why did you get that idea?
450 2012-01-23 05:27:54 <josephcp> namecoin isn't a scam
451 2012-01-23 05:28:14 <cjdelisle> I'm not trying to insult the NMC developers, it's just that that is how the structure turns out.
452 2012-01-23 05:28:25 <gmaxwell> cjdelisle: the price of registering names in namecoin falls exponentially... storing a bunch of nmc is stupid.
453 2012-01-23 05:29:14 <cjdelisle> bitcoin is a pyrimid scheme as well, it's just that I am content to have just one scheme because everyone who was going to get rich off of it already has and at this point is is just usefull.
454 2012-01-23 05:29:40 <cjdelisle> as are paper currencies
455 2012-01-23 05:30:13 <cjdelisle> what I'm saying is: lets have just one, that way we don't have to be making any more millionares
456 2012-01-23 05:30:35 <gmaxwell> cjdelisle: namecoin hasn't made won't make, can't make any millionares.
457 2012-01-23 05:30:52 <gmaxwell> Which actually sucks, because there is no way to fund e.g. buying a real DNS TLD for it.
458 2012-01-23 05:31:27 <Diablo-D3> damnit
459 2012-01-23 05:31:29 <Diablo-D3> sanity time
460 2012-01-23 05:31:36 <Diablo-D3> rotate(0x00000100, 15) ^ rotate(0x00000100, 13) ^ (0x00000100 >> 10)
461 2012-01-23 05:31:39 <Diablo-D3> whats the answer to this
462 2012-01-23 05:31:51 <cjdelisle> rotr or rotl?
463 2012-01-23 05:32:29 <cjdelisle> anyway, from a technical standpoint, nmc is inadaquate for me since everyone needs the whole chain to do anything.
464 2012-01-23 05:32:40 <cjdelisle> *to prove anyhing
465 2012-01-23 05:33:05 <Diablo-D3> cjdelisle: er
466 2012-01-23 05:33:10 <gmaxwell> cjdelisle: but NMC could actually be changed to flip mode far more easily that bitcoin could be.
467 2012-01-23 05:33:30 <gmaxwell> cjdelisle: go code that, people will probably change to it considering that namecoin's developer has vanished.
468 2012-01-23 05:33:31 <josephcp> well.. how else could you design it to work, NMC was designed that way because it works
469 2012-01-23 05:34:04 <Diablo-D3> cjdelisle: I think rotate in ocl is left
470 2012-01-23 05:34:06 <gmaxwell> josephcp: like this https://bitcointalk.org/index.php?topic=21995.0
471 2012-01-23 05:34:36 <cjdelisle> I have the design in my head, I just have to deal with the thorny issue of howto waste a given amount of bitcoin.
472 2012-01-23 05:34:59 <josephcp> gmaxwell: so it's namecoin but with no ownership transfers?
473 2012-01-23 05:35:12 <gmaxwell> 0_
474 2012-01-23 05:35:40 <josephcp> yeah that could work
475 2012-01-23 05:35:44 <josephcp> interesting!
476 2012-01-23 05:36:02 <Diablo-D3> man I wish there was a useful command line calculator I could just throw these into
477 2012-01-23 05:36:17 <cjdelisle> same thing in a little bit more detail: http://btc.pastebay.com/144544
478 2012-01-23 05:36:28 <cjdelisle> unless I made a booboo
479 2012-01-23 05:39:44 <Diablo-D3> I find this fucking amazing wolfram alpha cant fucking rotate
480 2012-01-23 05:41:36 <Diablo-D3> wait
481 2012-01-23 05:41:37 <Diablo-D3> it can
482 2012-01-23 05:41:43 <Diablo-D3> the command, apparently, is rotateleft
483 2012-01-23 05:41:44 <Diablo-D3> what the fuck wa
484 2012-01-23 05:43:10 <cjdelisle> Diablo-D3: http://pastebay.com/302622
485 2012-01-23 05:43:28 <Diablo-D3> er, node.js. _heh_.
486 2012-01-23 05:43:39 <Diablo-D3> cjdelisle: UH
487 2012-01-23 05:43:47 <Diablo-D3> that doesnt look right
488 2012-01-23 05:43:52 <cjdelisle> I did a few sanity checks to make sure it really was operating on 32 bit numbers
489 2012-01-23 05:43:58 <cjdelisle> because node is weird
490 2012-01-23 05:44:16 <Diablo-D3> http://www.wolframalpha.com/input/?i=rotateleft%280x00000100%2C+15%29+^+rotateleft%280x00000100%2C+13%29+^+%280x00000100+%3E%3E+10%29
491 2012-01-23 05:44:22 <cjdelisle> that's left rotate, right rotate will be different
492 2012-01-23 05:44:51 <Diablo-D3> I just double checked the opencl spec, its left
493 2012-01-23 05:45:04 <Diablo-D3> gentype rotate (gentype v, gentype i)
494 2012-01-23 05:45:11 <Diablo-D3> For each element in v, the bits are shifted left by
495 2012-01-23 05:45:13 <Diablo-D3> right.
496 2012-01-23 05:46:30 <Diablo-D3> cjdelisle: so WA says its 10.
497 2012-01-23 05:46:44 <Diablo-D3> well, 10 in hex
498 2012-01-23 05:47:12 <Diablo-D3> WA is on drugs, Im using ten, its wrong
499 2012-01-23 05:48:16 <cjdelisle> > console.log(0x800000 ^ 0x200000 ^ 0);
500 2012-01-23 05:48:17 <cjdelisle> 10485760
501 2012-01-23 05:48:39 <cjdelisle> just did them manually on the calculator and plugged in the outputs
502 2012-01-23 05:50:09 <Diablo-D3> wtf wa is fucktarded
503 2012-01-23 05:50:27 <cjdelisle> my number work?
504 2012-01-23 05:50:46 <Diablo-D3> trying
505 2012-01-23 05:51:02 <Diablo-D3> yes =/
506 2012-01-23 05:51:14 <cjdelisle> cools
507 2012-01-23 05:51:32 <cjdelisle> it's 0xA00000 if you like hex
508 2012-01-23 05:51:42 <cjdelisle> heh
509 2012-01-23 05:54:09 <Diablo-D3> does nodejs have a way to output hex?
510 2012-01-23 05:55:04 <cjdelisle> I did that in my calculator but maybe...
511 2012-01-23 05:56:11 <cjdelisle> > console.log((0x800000 ^ 0x200000 ^ 0).toString(16));
512 2012-01-23 05:56:12 <cjdelisle> a00000
513 2012-01-23 05:56:26 <Diablo-D3> goddamnit fucking javaism
514 2012-01-23 06:03:49 <Diablo-D3> cjdelisle: nodejs hates me
515 2012-01-23 06:04:01 <Diablo-D3> rotate(0x80000000, 25) ^ rotate(0x80000000, 14) ^ (0x80000000 >> 3)
516 2012-01-23 06:04:59 <cjdelisle> same rotate definition?
517 2012-01-23 06:05:06 <Diablo-D3> yeah
518 2012-01-23 06:05:38 <Diablo-D3> 0xf0ffe000 seems to be what its trying to tell me
519 2012-01-23 06:06:37 <cjdelisle> --- negative
520 2012-01-23 06:06:45 <Diablo-D3> yes, but its unsigned int
521 2012-01-23 06:06:46 <cjdelisle> hmm
522 2012-01-23 06:06:55 <cjdelisle> not in node's little mind
523 2012-01-23 06:08:09 <Diablo-D3> its not 0f0002000 either
524 2012-01-23 06:08:22 <cjdelisle> http://pastebay.com/302625
525 2012-01-23 06:08:24 <cjdelisle> my mistake
526 2012-01-23 06:08:33 <cjdelisle> hate signed numbers
527 2012-01-23 06:08:48 <Diablo-D3> :D
528 2012-01-23 06:09:42 <cjdelisle> btw, some of this stuff is easy to do in C rather than node
529 2012-01-23 06:10:12 <Diablo-D3> probably, but it seems fucktarded I have to write a program to do basic math
530 2012-01-23 06:11:21 <cjdelisle> mhm
531 2012-01-23 06:14:22 <Diablo-D3> apt-get install c-repl
532 2012-01-23 06:14:23 <Diablo-D3> lawlz
533 2012-01-23 06:17:12 <cjdelisle> ya gotta print to stderr
534 2012-01-23 06:17:24 <cjdelisle> and #include <stdint.h> didn't work for me
535 2012-01-23 06:17:26 <cjdelisle> but cool
536 2012-01-23 06:17:44 <Diablo-D3> I just typed in printf("hi") by itself
537 2012-01-23 06:17:46 <Diablo-D3> and it worked
538 2012-01-23 06:17:52 <cjdelisle> hmm ok
539 2012-01-23 06:18:07 <cjdelisle> > printf("hi");
540 2012-01-23 06:18:08 <cjdelisle> >
541 2012-01-23 06:18:09 <Diablo-D3> er, and \n
542 2012-01-23 06:18:11 <cjdelisle> oh well
543 2012-01-23 06:18:15 <cjdelisle> oic
544 2012-01-23 06:18:29 <cjdelisle> haha stdout didn't flush
545 2012-01-23 06:25:06 <CIA-76> bitcoin: L. Grondin * re4865cb7d131 libbitcoin-perl/ (20 files in 5 dirs): master keys and signing overloading http://tinyurl.com/6s2rnr3
546 2012-01-23 06:25:18 <Diablo-D3> int rotate(int x, int y) { return (x << y | (x >> (32 - y))); };
547 2012-01-23 06:25:27 <Diablo-D3> printf("%x\n", rotate(0x80000000,25) ^ rotate(0x80000000, 14) ^ (0x80000000 >> 3));
548 2012-01-23 06:25:31 <Diablo-D3> so lets see if that works
549 2012-01-23 06:26:39 <Diablo-D3> OH COME ON
550 2012-01-23 06:26:59 <Diablo-D3> WORK DAMNIT
551 2012-01-23 06:30:48 <cjdelisle> erm
552 2012-01-23 06:30:51 <Diablo-D3> C[0], which is that number.
553 2012-01-23 06:32:14 <cjdelisle> > unsigned int rotate(unsigned int x, unsigned int y) { return (x << y | (x >> (32 - y))); };
554 2012-01-23 06:32:17 <cjdelisle> > printf("%x\n", (rotate(0x80000000,25) ^ rotate(0x80000000, 14) ^ (0x80000000 >> 3)));
555 2012-01-23 06:32:20 <cjdelisle> 11002000
556 2012-01-23 06:32:34 <Diablo-D3> wtf, those should already be signed!
557 2012-01-23 06:34:53 <Diablo-D3> damnit now it works
558 2012-01-23 06:38:54 <Diablo-D3> okay I think this optimization was effective
559 2012-01-23 06:39:13 <Diablo-D3> so maybe those were those missing 100 instructions
560 2012-01-23 06:43:53 <CIA-76> DiabloMiner: Patrick McFarland master * re5a1b3c / (2 files in 2 dirs): Added a few more kernel optimizations - http://git.io/y9laLw https://github.com/Diablo-D3/DiabloMiner/commit/e5a1b3c2e46114ecd13384215a445dbf7c58580e
561 2012-01-23 06:48:31 <Diablo-D3> reboot time
562 2012-01-23 06:48:39 <Diablo-D3> gonna see if kernel analyzer isnt lying out its ass again
563 2012-01-23 06:56:27 <Diablo-D3> WAAAARGH
564 2012-01-23 06:57:06 <Diablo-D3> 5870: 21 ghr, 1505 alu, 75.22 cycles, 71 cf
565 2012-01-23 06:57:40 <Diablo-D3> 6970: 23 gpr, 1695 alu, 70.60 cycles, 71 cf
566 2012-01-23 06:58:31 <Diablo-D3> vs
567 2012-01-23 07:01:04 <Diablo-D3> newest diapolo
568 2012-01-23 07:01:25 <Diablo-D3> 5870: 21 gpr, 1394 alu, 69.70 cycles, 67 cf
569 2012-01-23 07:01:54 <Diablo-D3> 6970: 20 gpr, 1687 alu, 70.29 cycles, 66 cf
570 2012-01-23 07:03:21 <Diablo-D3> SO WHY THE HELL ISNT IT ANY FASTER
571 2012-01-23 07:03:27 <Diablo-D3> GODDAMNIT KERNEL ANALYZER
572 2012-01-23 07:03:56 <cjdelisle> optimizing compiler beat you to it?
573 2012-01-23 07:04:16 <Diablo-D3> no, I shaved off 3 cycles with this shit
574 2012-01-23 07:04:28 <Diablo-D3> but how the fuck is diapolos 100 cycles faster in kernel analyzer
575 2012-01-23 07:04:31 <Diablo-D3> it makes no fucking sense
576 2012-01-23 07:04:39 <cjdelisle> ahh
577 2012-01-23 07:05:03 <Diablo-D3> diapolo calling all the same fucking instructions I am
578 2012-01-23 07:05:24 <sktigerjs> hey guys
579 2012-01-23 07:05:44 <sktigerjs> any traders here?
580 2012-01-23 09:25:10 <CIA-76> bitcoin: p2k * rbcedd91add0d ecoinpool/ (6 files in 5 dirs): Error handling on new user setup http://tinyurl.com/6os4b56
581 2012-01-23 10:35:09 <CIA-76> bitcoin: p2k * rc89ef810109e cgminer/api.c: Fixed API compiling issue on OS X http://tinyurl.com/7apvruz
582 2012-01-23 10:35:11 <CIA-76> bitcoin: Con Kolivas * r22a1850cbc90 cgminer/api.c: Merge pull request #90 from p2k/master http://tinyurl.com/7xuj96d
583 2012-01-23 11:01:29 <Joric> to whom it may concern :) i added cryptography https://github.com/joric/pywallet
584 2012-01-23 11:02:39 <Joric> it is actually just 25000+ rounds of sha512, not 25000+ rounds of aes
585 2012-01-23 11:04:12 <Joric> just a few rounds sha512(passphrase + salt), then we're using 0-31 as the aes key, 32-48 as iv
586 2012-01-23 11:10:38 <Joric> simple example: http://pastebin.com/XWibUePh
587 2012-01-23 11:54:28 <Internet13> ????
588 2012-01-23 12:11:09 <Joric> etotheipi_, i added encrypted wallets support this morning https://bitcointalk.org/index.php?topic=34028.100
589 2012-01-23 12:53:29 <TuxBlackEdo> morning gavinandresen
590 2012-01-23 12:53:35 <gavinandresen> good morning
591 2012-01-23 12:53:50 <TuxBlackEdo> hehe it's just me and the lead bitcoin dev... my dreams have come true
592 2012-01-23 12:55:55 <Joric> you wish
593 2012-01-23 12:56:58 <gavinandresen> You should dream bigger
594 2012-01-23 12:57:08 <Joric> i wrote python code for decrypting wallets https://bitcointalk.org/index.php?topic=34028.100
595 2012-01-23 12:57:49 <Joric> thought there will be 25k aes rounds but it was only sha512 :)
596 2012-01-23 13:00:11 <Joric> pretty fast, even with pure python
597 2012-01-23 13:00:37 <Joric> assuming sha512 is native )
598 2012-01-23 13:01:30 <gavinandresen> [Tycho] : If I personally guaranteed that if a problem with p2sh made your pool mine an invalid block (up to, say, 10 blocks), would you be willing to deploy it sooner?
599 2012-01-23 13:02:10 <ThomasV> Joric: why don't you use slowaes?
600 2012-01-23 13:02:22 <[Tycho]> Actually I didn't planned to deploy p2sh.
601 2012-01-23 13:02:39 <gavinandresen> Why not?
602 2012-01-23 13:02:44 <Joric> ThomasV, huh? look closer
603 2012-01-23 13:02:58 <[Tycho]> It looks like a bad solution to me.
604 2012-01-23 13:03:15 <ThomasV> Joric: oh sorry
605 2012-01-23 13:03:25 <gavinandresen> Well then why haven't you been posting to the forums or bitcoin-development explaining your position?
606 2012-01-23 13:03:31 <gavinandresen> ... or suggesting something better?
607 2012-01-23 13:03:33 <[Tycho]> But, of course, I'll deploy it if voting will show 55%+ of expected support.
608 2012-01-23 13:04:00 <[Tycho]> I told my opinion to you, luke and slush.
609 2012-01-23 13:04:03 <gavinandresen> I'm disappointed that you haven't been participating in the process, and are now are just saying "no"
610 2012-01-23 13:04:31 <gavinandresen> Yes, you have said you don't like that the script is serialized, which I don't understand
611 2012-01-23 13:04:48 <gavinandresen> (since scripts are serialized in every single tx message)
612 2012-01-23 13:04:56 <[Tycho]> The thing I don't like most is the "special case".
613 2012-01-23 13:05:06 <ThomasV> hey gavinandresen; I heard that the next version of bitcoin will support bitcoin: URIs ; is that true?
614 2012-01-23 13:05:16 <gavinandresen> But the special case is what makes it much safer than a more general solution
615 2012-01-23 13:05:45 <gavinandresen> ThomasV: ask wumpus, he's Mr. Bitcoin GUI.
616 2012-01-23 13:05:46 <[Tycho]> (btw, I don't understand your phrase about guarantee)
617 2012-01-23 13:06:11 <gavinandresen> [Tycho]: I'm saying that if there is a problem with p2sh and your pool mined a block that got orphaned, I would reimburse you for the lost revenue
618 2012-01-23 13:06:20 <ThomasV> wumpus: are you Mr. Bitcoin: URI ?
619 2012-01-23 13:06:26 <gavinandresen> ... because I am confident that the p2sh solution is safe and secure
620 2012-01-23 13:06:28 <Joric> you should hire the apple guy
621 2012-01-23 13:06:30 <Eliel> [Tycho]: did you read this thread yet? https://bitcointalk.org/index.php?topic=60433.0
622 2012-01-23 13:06:39 <[Tycho]> gavinandresen: at this moment I think that the best way is to support plain multisig and long-address multisigs before continuing to pay-to-scripts.
623 2012-01-23 13:06:51 <[Tycho]> Eliel: no.
624 2012-01-23 13:07:06 <wumpus> ThomasV: yes
625 2012-01-23 13:07:13 <gavinandresen> [Tycho]: ok. I think it is wrong of you to use your position as the biggest pool operator to go against the general consensus.
626 2012-01-23 13:07:28 <[Tycho]> There is NO general consensus.
627 2012-01-23 13:07:32 <ThomasV> wumpus: what are the bitcoin: URI specs that will be supported?
628 2012-01-23 13:07:44 <[Tycho]> I see only ONE pool mining votes for p2sh currently. How do you call this a "consensus" ?
629 2012-01-23 13:08:48 <gavinandresen> Consensus among developers and users-- see luke's pool in the mining pools, thread, for example
630 2012-01-23 13:08:50 <[Tycho]> If there were at least some part of pools, then I would consider re-thinking my position.
631 2012-01-23 13:08:57 <wumpus> ThomasV: bitcoin:<address>&amount=<amount>&label=<label>
632 2012-01-23 13:09:01 <gavinandresen> There is definitely consensus a short multisig bitcoin address is needed
633 2012-01-23 13:09:28 <wumpus> ThomasV: it already supports these with 0.5, you can drag such a URL to the client
634 2012-01-23 13:09:33 <ThomasV> wumpus: ok, but in which unist is the amount expressed? I saw some funky stuff on the wiki
635 2012-01-23 13:09:34 <[Tycho]> But how can I agree to p2sh if everyone else is against it ?
636 2012-01-23 13:09:40 <gavinandresen> [Tycho]: ok. Three big pools have said they're in the middle of deploying it.
637 2012-01-23 13:09:41 <ThomasV> *units*
638 2012-01-23 13:09:55 <wumpus> ThomasV: it doesn't support the fancy stuff.. just 1.5 for 1.5 BTC
639 2012-01-23 13:10:15 <ThomasV> ah ok; I just want to make Electrum consistent with the official client
640 2012-01-23 13:10:22 <[Tycho]> That's exactly the thing. I don't want to oppose everyone.
641 2012-01-23 13:10:39 <wumpus> ThomasV: so you're the electrum maintainer? nice work!
642 2012-01-23 13:11:03 <ThomasV> yes
643 2012-01-23 13:11:21 <gavinandresen> [Tycho]: thanks. I'll be working on helping pools rollout this week, we'll see where we are Feb 1....
644 2012-01-23 13:11:26 <[Tycho]> As for the "security" question: we should either have scripts or no scripts, but only allowing special cases looks very wrong to me.
645 2012-01-23 13:11:48 <gavinandresen> [Tycho]: that's a good argument for another day, I think.
646 2012-01-23 13:12:04 <gavinandresen> [Tycho]: ... and an even harder argument than short multisig bitcoin addresses, I think
647 2012-01-23 13:12:48 <[Tycho]> As I said yesterday - it's like having a C IDE and compiler that only allows "Hello world" and "factorial" programs to be created. Why bother with compilation then ?
648 2012-01-23 13:13:05 <Eliel> [Tycho]: it's a special case that allows any script to be used if it's used. No special cases within the scripts it supports.
649 2012-01-23 13:13:21 <gavinandresen> [Tycho]: it gives a smooth upgrade path
650 2012-01-23 13:13:35 <Eliel> So, if we end up transitioning to that completely, it effectively just becomes protocol
651 2012-01-23 13:14:28 <[Tycho]> Can you elaborate why don't you like to split this upgrade into two consecutive steps ? Like multisigs first and pay-to-scripts second ?
652 2012-01-23 13:14:59 <gavinandresen> Sure-- because it is a TON of work for somebody to get people to upgrade, and I really don't want to do all that work twice
653 2012-01-23 13:15:38 <Eliel> [Tycho]: doing multisigs first would introduce one more address type that needs to be supported for a long time.
654 2012-01-23 13:15:43 <[Tycho]> They don't have to upgrade for the first step because there is no forking danger there.
655 2012-01-23 13:16:10 <gavinandresen> Sending multisig transactions is useless for people who aren't pool operators if they won't get relayed/mined
656 2012-01-23 13:16:51 <[Tycho]> Eliel: plain multisigs can be used without combined address too, even more clear. And this "one more address type" can be supported easily with pay-to-scripts.
657 2012-01-23 13:17:22 <[Tycho]> gavinandresen: convincing some pool ops to upgrade is not so difficult.
658 2012-01-23 13:17:57 <gavinandresen> [Tycho]: oh, they'll AGREE to upgrade, but getting them to actually take the time to do it....
659 2012-01-23 13:18:07 <Eliel> [Tycho]: It's an usability issue to me, mostly.
660 2012-01-23 13:18:49 <[Tycho]> gavinandresen: it's only needs to be included in IsStandard, yes ? Not so complicated.
661 2012-01-23 13:18:56 <gavinandresen> [Tycho]: frankly, the changes to support multisignature worry me more than p2sh
662 2012-01-23 13:19:28 <gavinandresen> [Tycho]: the real danger with multisig-as-standard is increasing the allowed scriptSig size to create enough room for the signatures
663 2012-01-23 13:19:57 <Joric> it's falling
664 2012-01-23 13:20:12 <[Tycho]> gavinandresen: how many can fit there ?
665 2012-01-23 13:20:14 <gavinandresen> [Tycho]: I THINK the current fee rules will be enough to prevent people creating bigger transactions just to spam the chain.....
666 2012-01-23 13:20:26 <[Tycho]> TuxBlackEdo: how can it ?
667 2012-01-23 13:20:44 <gavinandresen> [Tycho]: multisig changes scriptSig max size from 200 bytes to 500 bytes, so 3 signatures+public keys will fit
668 2012-01-23 13:21:05 <gavinandresen> (max "IsStandard" size)
669 2012-01-23 13:21:07 <helo> "Mining pools halt bitcoin development"
670 2012-01-23 13:21:09 <[Tycho]> Is the soft limit or network-enforced limit ?
671 2012-01-23 13:21:14 <[Tycho]> Oh, soft one.
672 2012-01-23 13:21:16 <gavinandresen> yes
673 2012-01-23 13:21:47 <[Tycho]> Can it work with pubkeyhashes instead of pubkeys ?
674 2012-01-23 13:22:03 <slush> helo: not all pools :-)
675 2012-01-23 13:22:06 <gavinandresen> That just makes the transaction even bigger....
676 2012-01-23 13:22:09 <[Tycho]> helo: mining pools save bitcoin from development !
677 2012-01-23 13:22:24 <[Tycho]> gavinandresen: just asked.
678 2012-01-23 13:23:50 <[Tycho]> Is this what luke-jr created ? https://bitcointalk.org/index.php?topic=60433.0
679 2012-01-23 13:24:08 <gavinandresen> [Tycho]: yes
680 2012-01-23 13:24:19 <Eliel> BIP 17 is luke's suggestion for how to implement it.
681 2012-01-23 13:25:06 <[Tycho]> "OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)" - why OP_0 and signature are outside of serialized part ?
682 2012-01-23 13:25:19 <[Tycho]> Oh, I got it.
683 2012-01-23 13:29:36 <[Tycho]> As for the "That means a maximum of 1,000 BIP-17-style multisig inputs per block" part - that's ok. Let people use fees for that, at last :)
684 2012-01-23 13:30:07 <gmaxwell> [Tycho]: The seralization is important for a couple reasons, some security warm fuzzies, etc, but most pratically because CHECKMULTISIG counts as 20 in the current rules enforced by every node. Seralizing it hides it, and then P2SH accounts for them correctly, so you don't bump into the 20k sigs limit so quickly.
685 2012-01-23 13:30:56 <gmaxwell> [Tycho]: 1000 inputs is a low fewer transactions than we can currently support :(
686 2012-01-23 13:31:18 <[Tycho]> "low fewer" ?
687 2012-01-23 13:31:40 <Eliel> I think gmaxwell tried to say "a lot fewer"
688 2012-01-23 13:31:42 <gmaxwell> [Tycho]: lot fewer. assuming lots of people switch to doing 2-of-2/3 for wallet security you'd be substantially reducing the capacity of bitcoin from the current levels.
689 2012-01-23 13:33:21 <Eliel> that's only a problem if we expect to be hitting those limits very soon.
690 2012-01-23 13:34:13 <gavinandresen> Nobody knows how quickly or slowly those limits will be reached.
691 2012-01-23 13:34:22 <gavinandresen> I don't think anybody CAN know, either....
692 2012-01-23 13:34:34 <gmaxwell> Eliel: I'm pretty sure we've had blocks with 1000 inputs.
693 2012-01-23 13:35:36 <Eliel> hmm, true, that is an important point.
694 2012-01-23 13:36:36 <gmaxwell> It means that without the packing there is an incentive to use the old transaction style just from block capacity.
695 2012-01-23 13:38:56 <Eliel> I think luke will give up his resistance to BIP 16 if it gets extra wording that states that the goal is to move completely away from old style transactions eventually.
696 2012-01-23 13:41:57 <gmaxwell> Eliel: He indicated that he would, I asked him to come up with language. Kind of ironic that his own proposal actually makes moving away from the old style harder by not freeing up the multisig overcounting.
697 2012-01-23 13:43:38 <[Tycho]> 20000 limit is network-enforced ?
698 2012-01-23 13:43:55 <gavinandresen> [Tycho]: yes, hard limit
699 2012-01-23 13:44:11 <gavinandresen> [Tycho]: it is defined as 1/50'th of the maximum block size
700 2012-01-23 13:44:59 <gavinandresen> Maximum number of inputs we've ever had so far is 1,837 (I just ran a little python code on the block chain)
701 2012-01-23 13:45:30 <Eliel> when was that? sometime in june?
702 2012-01-23 13:45:43 <gavinandresen> ... let me modify my code to spit out the block date...
703 2012-01-23 13:52:41 <[Tycho]> That argument about 1000 txes is at least important.
704 2012-01-23 13:53:12 <[Tycho]> Not that I believe we may hit this limit anytime soon, but I know that people are always wrong by thinking that :)
705 2012-01-23 13:53:22 <roconnor> etotheipi_: ping
706 2012-01-23 13:53:51 <gavinandresen> ... wish block explorer let me search by timestamp...
707 2012-01-23 13:54:37 <etotheipi_> roconnor, I'm here, but I desperately need to go to work soon
708 2012-01-23 13:54:57 <gavinandresen> According to my tool, block with the most transaction inputs was 2012-01-11 19:29:17 GMT
709 2012-01-23 13:55:08 <etotheipi_> (so please don't nerd snipe me into a 3 hr conversation about alternate hashcodes :))
710 2012-01-23 13:57:08 <roconnor> etotheipi_: I wanted to comment about armory, but let's do it tonight instead
711 2012-01-23 13:57:19 <gavinandresen> There we go, this block has 1,837 inputs: http://blockexplorer.com/block/0000000000000bb3160a09e22a52d6a0a260522b8ca705fc064f1c96a5eac7f6
712 2012-01-23 13:57:44 <etotheipi_> roconnor, sure, I will be around later
713 2012-01-23 13:57:45 <gavinandresen> The other top 49 are here: https://gist.github.com/1663506
714 2012-01-23 13:58:06 <sipa> [Tycho]: to continue with your C compiler analogy: it is like first having C, supporting many kinds of programs, and then adding a rule "the program is allowed to be the single line '#include <filename>', in which case we look there
715 2012-01-23 13:58:08 <etotheipi_> roconnor, btw, no comments are allowed on sending tx, locking outputs, spending your own change, etc... that's all fixed after I find this last bug
716 2012-01-23 13:58:40 <sipa> [Tycho]: as a primitive preprocessor
717 2012-01-23 13:58:49 <etotheipi_> zero-conf handling got a complete, *proper* makeover in Armory
718 2012-01-23 14:00:53 <[Tycho]> I don't like being restricted by limits, but it would be funny to see fees finally working :)
719 2012-01-23 14:01:48 <gavinandresen> Re-implementing fee-setting and fee-handling is still high on my TODO list
720 2012-01-23 14:02:28 <gavinandresen> ... that's something I would very much like to talk with you about sometime, [Tycho]
721 2012-01-23 14:03:46 <sipa> gavinandresen: as soon as i get the ip address managing thing done, i plan to redo rejectedtx (to allow non-confirming or conflicting transactions to be retracted)
722 2012-01-23 14:04:18 <gavinandresen> sipa: great, that will help. They'll show up as "rejected" in the GUI?
723 2012-01-23 14:04:20 <Eliel> gavinandresen: looking at the transactions in that block, it's pretty clear why there was a huge amoutn of inputs... those transactions are composed of huge amounts of small inputs.
724 2012-01-23 14:04:29 <gavinandresen> Eliel: yup
725 2012-01-23 14:04:30 <sipa> gavinandresen: yes, that's the plan
726 2012-01-23 14:05:33 <[Tycho]> At this moment I'm trying to "support" free TXes as long as possible. I know that some miners want to earn fees, but the possibility of free bitcoin transfers looks to me as very cool and important feature.
727 2012-01-23 14:05:45 <Eliel> now, the question is, if the limit is hit, will it start by delaying those txs with overblown inputs?
728 2012-01-23 14:06:04 <[Tycho]> Eliel: those TXes should be non-free, obviously.
729 2012-01-23 14:06:25 <Eliel> yes, they have pretty hefty fees attached
730 2012-01-23 14:06:26 <[Tycho]> Also I think that 0.0005 BTC fee is laughable because it's almost zero.
731 2012-01-23 14:06:45 <sipa> It's mostly symbolic, imho
732 2012-01-23 14:07:02 <sipa> to prevent people fro; believing bitcoin trqnsqctions qre free
733 2012-01-23 14:07:12 <Eliel> [Tycho]: the fee size basically sets the minimum transaction size that's practical, so it ought to be pretty low.
734 2012-01-23 14:07:16 <[Tycho]> I remember the spike in fee revenue when the official client wanted 0.01 for some TXes :)
735 2012-01-23 14:07:42 <UukGoblin> there's still a lot of txns with 0.01 fee
736 2012-01-23 14:08:01 <UukGoblin> earned one with 0.20 BTC worth of fees the other day
737 2012-01-23 14:08:30 <diki> UukGoblin:you found a block?
738 2012-01-23 14:08:33 <[Tycho]> My nodes are using 0.01 as minimal fee for non-free TXes. Actually I think that 0.01 is pretty small, but at least something to start with.
739 2012-01-23 14:08:34 <diki> congrats
740 2012-01-23 14:08:42 <UukGoblin> diki, p2pool.
741 2012-01-23 14:09:24 <UukGoblin> [Tycho], well, I remember it was lowered to 0.0005 because the price of bitcoin went up like 10-fold at the time
742 2012-01-23 14:09:42 <UukGoblin> and 30 cents fee for a txns seemed quite high
743 2012-01-23 14:10:02 <luke-jr> gmaxwell: BIP 17 does not make P2SH-only any more difficult; the multisig overcounting only halves the max transactions per block, and only if everyone uses multisig (that is, not all P2SH require multisig&)
744 2012-01-23 14:11:18 <gmaxwell> luke-jr: you're making the mistake of assuming one input per transaction. I think the current mean is like 3-4 inputs.
745 2012-01-23 14:12:00 <luke-jr> gmaxwell: my point is that BIP 17 does not make the current limits any worse than they already are
746 2012-01-23 14:12:49 <gmaxwell> luke-jr: The current limit isn't very relevant because no one uses checkmultisig. The purpose of P2SH is to make it easy for everyone to use it, so the limit matters.
747 2012-01-23 14:13:24 <luke-jr> gmaxwell: that's unrelated to moving to a P2SH-only scheme in the future, though
748 2012-01-23 14:13:40 <gmaxwell> [Tycho]: That threshold needs to be small enough that most people see it as 'basically free', so they don't get angry about being forced to pay it, but still large enough that it really adds up for a spammer.
749 2012-01-23 14:13:46 <josephcp> everyone copy+pastes addresses anyway, why isn't long multisig addresses implemented first and then this stuff considered later?
750 2012-01-23 14:14:06 <etotheipi_> josephcp, +1
751 2012-01-23 14:14:45 <luke-jr> josephcp: perhaps if someone does it, it will be taken more seriously; I don't know if it's practical, though
752 2012-01-23 14:14:58 <josephcp> i really really dislike the idea of p2sh only
753 2012-01-23 14:15:07 <luke-jr> https://github.com/luke-jr/bitcoin/commit/6cd6788798f2b0637a730baba22b907b9ec51413 reverts BIP 16 in theory, so you could build on top of that to try
754 2012-01-23 14:15:46 <gavinandresen> josephcp: ... so write a proposal for long multisig bitcoin addresses and see if you can get majority support.
755 2012-01-23 14:15:50 <luke-jr> (it does not revert multisig, nor sigop count changes - though the latter is effectively neutered)
756 2012-01-23 14:16:48 <etotheipi_> gavinandresen, I don't understand, OP_CHECKMULTSIG is already part of the protocol, tested, secure, and provides all the benefits of all these proposals, it's only issue is that it's suboptimal
757 2012-01-23 14:17:24 <[Tycho]> etotheipi_: it's not yet supported by the client.
758 2012-01-23 14:17:26 <gavinandresen> etotheipi_: I disagree that it is well-tested already; are there any OP_CHECKMULTISIG transactions in the main chain?
759 2012-01-23 14:17:40 <[Tycho]> You can only create them as strange TXes.
760 2012-01-23 14:17:53 <gavinandresen> etotheipi_: (except for the bogus ones in the infamouse CHECKMULTISIG block)
761 2012-01-23 14:17:53 <helo> everyone will always copy/paste addresses
762 2012-01-23 14:17:54 <etotheipi_> it's definitely supported by the client, once they are already in a block.... and they're all over the testnet
763 2012-01-23 14:18:05 <luke-jr> UsQmxuBo5uKPaotZc1jkKyvU1VXu7Gy6ZeaUrunKG7A1UrcP15JLePd26cDXtum <-- length of a 2-of-2 multisig literal-script-address
764 2012-01-23 14:18:10 <[Tycho]> Also I think that not only long-addresses should be supported, but completely plain multisigs too.
765 2012-01-23 14:18:49 <[Tycho]> etotheipi_: you still can't create them with the client.
766 2012-01-23 14:18:51 <etotheipi_> I am mistaken then, with everyone's level of comfort around OP_CHECKMULTISIG... I thought that was basically ready to go, and irritated that we were bypassing it
767 2012-01-23 14:18:58 <luke-jr> problem with literal-script-addresses: someone can easily craft one that LOOKS like another but isn't.
768 2012-01-23 14:19:24 <luke-jr> oops, I forgot the checksum on the end; that might help
769 2012-01-23 14:19:36 <etotheipi_> [Tycho],, one of the reasons I made Armory the way I did, was to support multi-sig in general... you can't create any of the proposals right now
770 2012-01-23 14:19:43 <luke-jr> 49NDZorKZ2RRcmPYMR7xQfajHpX8YcbqipaBUWSko1hxa1jvT6fuNySzW6T8qaxf9tnxf <-- with 4 byte checksum
771 2012-01-23 14:19:50 <gavinandresen> etotheipi_: I'm more worried about possible spamming/chain bloat with plain CHECKMULTISIG... but still think we should do it
772 2012-01-23 14:20:16 <[Tycho]> Chain bloat is OK, and spamming should be deferred by fees.
773 2012-01-23 14:20:18 <etotheipi_> gavinandresen, that's up to you guys... I don't know ALL the details about these proposals
774 2012-01-23 14:20:34 <gavinandresen> luke-jr: what are you serializing with your examples?
775 2012-01-23 14:20:47 <luke-jr> gavinandresen: "xff012345678901234567890012345678901234567890220hhhh"
776 2012-01-23 14:21:01 <gavinandresen> luke-jr: and that's supposed to represent... what?
777 2012-01-23 14:21:14 <luke-jr> gavinandresen: 21 bytes per address, plus 2 opcodes for Ns, plus an opcode for CHECKMULTISIG, plus a checksum
778 2012-01-23 14:21:28 <luke-jr> (it's just for length)
779 2012-01-23 14:21:42 <gavinandresen> plain multisig needs full public keys, so 33 bytes (compressed) or 65 bytes (uncompressed)
780 2012-01-23 14:22:03 <gmaxwell> josephcp: long multisig is bad for reasons unrelated to their length. You're effectively accepting script code from random people. Then you get fun stuff like jokers giving you 10kb codes and making you blead txn fees.
781 2012-01-23 14:22:13 <gavinandresen> ... unless you assume that the person sending the transaction somehow magically knows the public key --> hash mapping.... (bad assumption)
782 2012-01-23 14:22:24 <josephcp> well you'd hash it like with standard transactions today, weren't there some earlier proposals/examples?
783 2012-01-23 14:22:39 <gmaxwell> josephcp: !!! thats what p2sh is!
784 2012-01-23 14:22:46 <josephcp> no it's not
785 2012-01-23 14:22:49 <gavinandresen> If the public keys are hashed then we're not talking about CHECKMULTISIG any more, but some other transaction type
786 2012-01-23 14:22:49 <josephcp> well not what i meant
787 2012-01-23 14:22:50 <etotheipi_> gmaxwell, that's a good point
788 2012-01-23 14:23:04 <josephcp> with p2sh you're hashing the transaction string
789 2012-01-23 14:23:22 <gmaxwell> You're hasing the payment script.
790 2012-01-23 14:23:24 <josephcp> it's not checking the hash of the keys individiually
791 2012-01-23 14:23:34 <josephcp> yes payment script
792 2012-01-23 14:23:48 <etotheipi_> okay, I am partially persuaded... but now I have to go to my real job
793 2012-01-23 14:23:53 <gavinandresen> Right, I thought luke-jr was giving what addresses would look like in a "just plain CHECKMULTISIG" solution
794 2012-01-23 14:24:00 <josephcp> gmaxwell: currently single transactions are hash(pubkey), p2sh is hash(script)
795 2012-01-23 14:24:04 <luke-jr> gavinandresen: multisig can't handle hashes? wtf? O.o
796 2012-01-23 14:24:08 <[Tycho]> It wasn't quite plain :)
797 2012-01-23 14:24:18 <gmaxwell> josephcp: I could still give you a 10kb script that way. So then sites will impose their own random size limits to protect themselves, and then you'd generate addresses and find places refusing them.
798 2012-01-23 14:24:28 <gavinandresen> luke-jr: no, CHECKMULTISIG is plain-old m <pubkeys...> n OP_CHECKMULTISIG
799 2012-01-23 14:24:39 <josephcp> gmaxwell: my fear is if sha256(ripemd()), general MD-derived hashing is vulnerable
800 2012-01-23 14:24:44 <gavinandresen> ... where <pubkeys> are each either 33 or 65 bytes long
801 2012-01-23 14:24:50 <luke-jr> sigh
802 2012-01-23 14:25:00 <[Tycho]> Yeah, not cool.
803 2012-01-23 14:25:26 <gmaxwell> josephcp: you're worred about that more than ECDSA bing vulnerable? 0_o
804 2012-01-23 14:25:27 <josephcp> gmaxwell: under the current scheme it's not vulnerable to THEFT (but vulnerable to destruction) becuase it's secured by both MD-derived schemes AND ECC
805 2012-01-23 14:25:30 <[Tycho]> Requires you to know pubkeys of your victims.
806 2012-01-23 14:25:36 <luke-jr> ReZYdLNv1L9PuCe9FM3Z8XsN7QNdz2j5oKuVJG3j7o3ziTT1221sRHo827MXVSciA5LFwcMCnnrZPX9TLyYyXMVnrWEiUPuorv2BRfQT <-- real 2-of-2 multisig -.-
807 2012-01-23 14:25:41 <josephcp> ECDSA is protected, that's why new coins go to new addresses
808 2012-01-23 14:25:54 <gmaxwell> josephcp: no, ECDSA is vulnerable if you can create collissions of the hash, sadly.
809 2012-01-23 14:25:55 <josephcp> everyone thinks new addresses is for anonymity, it's not. it's for security
810 2012-01-23 14:26:05 <josephcp> yeah but it's a LOT harder
811 2012-01-23 14:26:17 <gavinandresen> luke-jr: my mac does ... interesting... things if I double-click on that address to try to copy/paste it....
812 2012-01-23 14:26:19 <josephcp> new address => ECDSA pubkey is NOT KNOWN
813 2012-01-23 14:26:22 <[Tycho]> Mostly I'm thinking about plain multisigs for escrow services, like 2-of-3, not the 2-factor auth.
814 2012-01-23 14:26:28 <luke-jr> gavinandresen: ?
815 2012-01-23 14:26:36 <gmaxwell> josephcp: yes, and thats the same thing with p2sh.
816 2012-01-23 14:26:42 <josephcp> that's why you generate a new address every time...
817 2012-01-23 14:26:57 <gavinandresen> luke-jr: interesting == I double click and it selects the address plus everything on the page above it. No idea why....
818 2012-01-23 14:27:00 <[Tycho]> Yeah, protection against quantum computers, sort of.
819 2012-01-23 14:27:12 <luke-jr> gmaxwell: he does have a small point. with p2sh, if you can collide, you can make a script of your own matching it
820 2012-01-23 14:27:22 <gmaxwell> josephcp: with P2SH you get the same property, except the address is H(pubkey+otherstuff) instead of H(pubkey)
821 2012-01-23 14:27:23 <josephcp> gmaxwell: chosen prefix collisions are vulnerable with p2sh, not with current
822 2012-01-23 14:27:25 <luke-jr> gmaxwell: right now, you need to know the ECDSA key too
823 2012-01-23 14:27:30 <gmaxwell> luke-jr: NO!
824 2012-01-23 14:27:34 <gmaxwell> luke-jr: you really don't.
825 2012-01-23 14:27:43 <gmaxwell> luke-jr: if you can collide you can rebind an existing signature.
826 2012-01-23 14:27:46 <josephcp> you can't do chosen prefix attacks with current bitcoin addresses because the pubkey is protected too
827 2012-01-23 14:28:13 <josephcp> (this is assuming current hash scheme is vulnerable, which i do admit is a TALL order)
828 2012-01-23 14:28:29 <gmaxwell> josephcp: the hash _inside_ ECDSA is vulnerable under chosen prefix collisions.
829 2012-01-23 14:28:57 <gavinandresen> Worrying about chosen prefix of ripemd(sha256()) seems like an unproductive use of time to me
830 2012-01-23 14:28:59 <josephcp> but you won't be able to steal the coins
831 2012-01-23 14:29:17 <josephcp> but this was an explicit choice in the design that is being removed is my concern
832 2012-01-23 14:29:42 <gmaxwell> josephcp: If you got the idea that the ecc attack resistance was an explicit choice in the design, you probably got it from me.
833 2012-01-23 14:29:51 <josephcp> the only way to maintain it with short addresses is to add in OP_CAT, which I understand is impossible from a systemic perspective
834 2012-01-23 14:30:15 <luke-jr> gavinandresen: can you confirm the explicit reason for using new addresses regularly is for privacy, and put this to rest? :P
835 2012-01-23 14:30:21 <josephcp> gmaxwell: i only started looking at bitcoin in detail recently, independently reached :-)
836 2012-01-23 14:30:50 <gmaxwell> josephcp: well, Satoshi never described it that way I did on the forum and got yelled at over it. :)
837 2012-01-23 14:31:12 <gmaxwell> josephcp: I think it was an accident. But whatever.
838 2012-01-23 14:31:18 <gavinandresen> luke-jr: the explicit reason for using new addresses is primarily privacy. Although it is also generally good security practice to not re-use keys if you don't have to, also.
839 2012-01-23 14:31:22 <josephcp> gmaxwell: oh? interesting, because this perfectly protects against ECDSA being broken
840 2012-01-23 14:31:38 <gmaxwell> josephcp: I know well, it makes the exposure window very small.
841 2012-01-23 14:31:53 <josephcp> i mean ECDSA and not MD-hashes
842 2012-01-23 14:31:59 <gmaxwell> josephcp: in any case, I can steal coins if I can collide the hash.
843 2012-01-23 14:32:20 <luke-jr> josephcp: not really.
844 2012-01-23 14:32:29 <luke-jr> josephcp: the moment you try to spend, your pubkey is known
845 2012-01-23 14:32:31 <gavinandresen> josephcp: If you look at the bigger picture, the REAL vulnerability we're seeing is people getting coins stolen from their private keys getting compromised.
846 2012-01-23 14:32:55 <gavinandresen> josephcp: ... and this whole thing is a reaction to that, so compromising private keys on one device isn't catastrophic.
847 2012-01-23 14:32:55 <josephcp> luke-jr: true, but that's like a 10minute window :-P
848 2012-01-23 14:32:57 <luke-jr> josephcp: at that point, anyone relaying it can redeem
849 2012-01-23 14:33:17 <josephcp> gavinandresen: i understand, it's just concerning to me, especially if there's wording to add in depreciating current methods in favor of p2sh
850 2012-01-23 14:33:29 <gmaxwell> josephcp: and we keep that property under P2SH. We're still exposed to hash breaks, but we are in the existing scheme.
851 2012-01-23 14:33:30 <luke-jr> josephcp: and if ECDSA is broken, you can be certain there will be such people out there
852 2012-01-23 14:33:43 <josephcp> and if this is causing so much drama, it feels like multisig long addresses would have less controversial issues?
853 2012-01-23 14:33:55 <gavinandresen> If ECDSA is broken we'll use one of the NOP opcodes to implement a secure replacement
854 2012-01-23 14:33:59 <josephcp> but i'm new here so i definitely am just stating my concerns and not recommending anything ;-)
855 2012-01-23 14:34:06 <UukGoblin> sorry to interrupt; can a transaction input spend an output that's in the same block?
856 2012-01-23 14:34:13 <gavinandresen> UukGoblin: yes
857 2012-01-23 14:34:13 <roconnor> armory protects against compromised private keys due to off-line transactions?
858 2012-01-23 14:34:31 <UukGoblin> gavinandresen, that's cool, thanks
859 2012-01-23 14:34:37 <nathan7> pew pew pew
860 2012-01-23 14:34:38 <gmaxwell> josephcp: long multisig has other problems as mentioned: it's an extra, new injection point for input that must be parsed, it will be attractive target for trouble makers with 10kb transactions
861 2012-01-23 14:34:42 <nathan7> I mean, hi earthlings
862 2012-01-23 14:34:57 <gmaxwell> josephcp: to prevent the 10kb transactions people will impose limits on what they'll pay to making them not relably usable.
863 2012-01-23 14:35:18 <gavinandresen> gmaxwell: I'd argue strongly against a general "just serialize the script" type of bitcoin address, by the way
864 2012-01-23 14:35:50 <gavinandresen> gmaxwell: It just seems WAY to juicy a target for a man-in-the-middle who will look for a slightly different script that base58-encodes to something that looks very much like the "real" address
865 2012-01-23 14:35:52 <luke-jr> biggest problem with "just serialize the script" is the risk of almost-collisions IMO
866 2012-01-23 14:36:00 <gavinandresen> luke-jr: exactly
867 2012-01-23 14:36:01 <josephcp> yeah i'm not saying a straight multisig pubkey is a good idea
868 2012-01-23 14:36:15 <luke-jr> josephcp: that's the only alternative to P2SH
869 2012-01-23 14:36:20 <gmaxwell> josephcp: https://bitcointalk.org/index.php?topic=10697.msg153521#msg153521 on the hash-pubkey security.
870 2012-01-23 14:36:21 <roconnor> gavinandresen: to prevent 10kb people will discount the trasnaction fee from the payment effectively making the reciepent pay for the transaction fee
871 2012-01-23 14:36:28 <roconnor> gavinandresen: opps
872 2012-01-23 14:36:30 <roconnor> that was for gmaxwell
873 2012-01-23 14:36:41 <josephcp> gmaxwell: thanks for link, i'll read through it
874 2012-01-23 14:36:44 <gmaxwell> roconnor: assuming that it's that kind of business deal.
875 2012-01-23 14:36:49 <josephcp> was trying to find it but couldn't find it
876 2012-01-23 14:37:46 <josephcp> gmaxwell: just read the comment, yeah that was exactly my point!
877 2012-01-23 14:37:50 <gmaxwell> roconnor: it's also still code that everyone would have to write.
878 2012-01-23 14:38:45 <luke-jr> gavinandresen: BTW, is there any chance you'd be willing to check that I've got all the BIP16-specific pieces in my revert patch? AFAIK you're the only person who knows all the stuff touched by BIP16& https://github.com/luke-jr/bitcoin/commit/6cd6788798f2b0637a730baba22b907b9ec51413
879 2012-01-23 14:39:05 <gmaxwell> josephcp: p2sh doesn't break that. It might arguably increase the risk of hash breaks (way better than ECC still) but if people feel thats dangerous, they could migrate away from using p2sh. though if the hash is vulnerable
880 2012-01-23 14:39:07 <josephcp> i read your message as something like 'satoshi yelled at you' and was searching all wrong -_-;
881 2012-01-23 14:39:15 <luke-jr> gavinandresen: (it's not intended to revert any of the BIP16-tied stuff like P2SH framework, sigop counting changes, nor multisig)
882 2012-01-23 14:39:23 <roconnor> gmaxwell: the code either adds the transaction fee to the sending side or subtracts the fee from the recipient side.
883 2012-01-23 14:39:26 <josephcp> yeah, hash breaking is my concern
884 2012-01-23 14:39:27 <gmaxwell> josephcp: we're vunerable all over... simply because I could rebind any signature I've already seen.
885 2012-01-23 14:40:04 <josephcp> true, but it just feels more risky
886 2012-01-23 14:40:23 <josephcp> the disagreement is whether it's worth it i guess..
887 2012-01-23 14:40:25 <luke-jr> josephcp: you know not even MD5 is broken in the way you're talking about, right?
888 2012-01-23 14:40:38 <josephcp> luke-jr: yes it is, you can do prefix attacks really easily
889 2012-01-23 14:40:49 <gmaxwell> roconnor: it requires that their front end actually know how to reason about transaction fees. We already see people losing coins because they're so freaked out about the current fee stuff (which can't charge more than 0.05 BTC ever) that they're hacking the software without understand it and losing change.
890 2012-01-23 14:41:09 <gavinandresen> luke-jr: you missed some code in bitcoinrpc.cpp and unit tests in test/