1 2013-01-29 00:37:24 <Diablo-D3> http://lmgtfy.com/?q=cache:lmgtfy.com
2 2013-01-29 00:38:48 <upb> haha
3 2013-01-29 01:00:38 <gmaxwell> ... '["022EC475351E2E9217477BED361FA4BDE7EE1FEF6936519969022C9709ED529F06","0340AC7033DC16436900002EEB90535A927845952B9F4E8693C49AD91474E77BF1","041ce5a954c9935de53a56c6724bf59b521ba370e54715dda45712c0bed083f3b692f2ea21dab22ac565153c729c552a887be4374d86fd6abcb8845a2e95d6a7b9","045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe4","04b85172458f3d63e27c066dc8a58 ...
4 2013-01-29 01:00:38 <gmaxwell> Okay, who's pubkeys are here: addmultisigaddress 2 ...
5 2013-01-29 01:00:44 <gmaxwell> ... 3fbf6629b6d8336ecb8c16357da691d49fb2781bd90febf3e46074fd70f756a71584e7223de18510ea781aebe452c4b78ae16","04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4"]'
6 2013-01-29 01:00:48 <gmaxwell> mine is the last one.
7 2013-01-29 01:01:30 <gmaxwell> 2409f355c8910721fbbb5c54a01b8f9c692cfb292c3b4f7baf5b8151e44fef21:0 is a generous donation of 10 BTC to that P2SH by one of the partipants in my 'I taint rich' thread.
8 2013-01-29 01:04:26 <Diablo-D3> wait, what?
9 2013-01-29 01:05:01 <gmaxwell> Diablo-D3: https://bitcointalk.org/index.php?topic=139581.0
10 2013-01-29 01:05:39 <petertodd> damn, and a 1BTC donation to miners too
11 2013-01-29 01:06:12 <Diablo-D3> gmaxwell: so whats the short version of that?
12 2013-01-29 01:06:31 <gmaxwell> Oh come on??? I know I'm long winded, but I tried to make it fun! :P
13 2013-01-29 01:09:00 <Diablo-D3> are we just trying to build the biggest multisig transaction or what?
14 2013-01-29 01:09:31 <gmaxwell> Diablo-D3: No. I'm trying to get my 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB address as a signer on many diverse and high value transactions.
15 2013-01-29 01:09:58 <Diablo-D3> just for lulz?
16 2013-01-29 01:10:00 <gmaxwell> so the fool tools that assume that all addresses that signed a single txn are one person and declare that I am all of bitcoin.
17 2013-01-29 01:10:45 <SomeoneWeird> hahahahah
18 2013-01-29 01:10:49 <SomeoneWeird> ++
19 2013-01-29 01:11:01 <gmaxwell> The lastest post in the thread involves 40,000 BTC.
20 2013-01-29 01:11:29 <Diablo-D3> gmaxwell: oh dear lord
21 2013-01-29 01:15:19 <petertodd> !
22 2013-01-29 01:15:54 <petertodd> you know, you might want to let people base their tx on your now linked to 40,000btc tx if it goes through...
23 2013-01-29 01:16:07 <petertodd> many do taint analysis many levels deep
24 2013-01-29 01:16:18 <gmaxwell> the taint stuff usually does full set linkage.
25 2013-01-29 01:16:33 <gmaxwell> But yea, I'll cycle that one back just to be sure.
26 2013-01-29 01:16:35 <phantomcircuit> DAG turns into a DG
27 2013-01-29 01:20:42 <gmaxwell> 69d9d66aae4812b6cf156f32267b773fb2118db696bb847ebd3454a198b59fbd I must admit a little finger tremble in handling 3/4 of a million paper dollars worth of bitcoin.
28 2013-01-29 01:21:50 <MC1984> wat
29 2013-01-29 01:21:50 <SomeoneWeird> 0___o
30 2013-01-29 01:22:28 <jgarzik> hah
31 2013-01-29 01:22:53 <SomeoneWeird> i can has?
32 2013-01-29 01:23:08 <Luke-Jr> gmaxwell: whose was that?
33 2013-01-29 01:23:16 <gmaxwell> "Loaded"
34 2013-01-29 01:23:23 <gmaxwell> (obviously!)
35 2013-01-29 01:23:27 <Diablo-D3> man, 3/4 of a million
36 2013-01-29 01:23:37 <Diablo-D3> almost enough to start on exelion
37 2013-01-29 01:23:49 <petertodd> did you double check he didn't use sighash_none?
38 2013-01-29 01:25:20 <gmaxwell> petertodd: yes, and this is also why I'm only using 1 BTC outputs.
39 2013-01-29 01:25:37 <gmaxwell> were it not for the screwup risk I'd move 1000 BTC or something.
40 2013-01-29 01:26:08 <gmaxwell> If someone tricks me with a transaction type thats okay. Good learning expirence.
41 2013-01-29 01:26:08 <petertodd> for sure, that first guy I really suspect he forgot to add in your 1btc when he did the calcs...
42 2013-01-29 01:26:22 <petertodd> 1.001 exact? hmm...
43 2013-01-29 01:26:57 <petertodd> that thread reminds me how far we need to go in making for solid tools to analize and review tx's
44 2013-01-29 01:27:01 <gmaxwell> petertodd: sadly, you're probably right??? like _10 seconds_ after I announced it I had another email from him with less fee.
45 2013-01-29 01:27:56 <Diablo-D3> heh, this is kinda cool
46 2013-01-29 01:28:03 <Diablo-D3> some kid's mother went on #bitcoin
47 2013-01-29 01:28:14 <Diablo-D3> to ask about bitcoins because her son wanted a bitcoin for his 18th birthday
48 2013-01-29 01:28:26 <gmaxwell> petertodd: I looked at his inputs to make sure he wasn't about to send a zillion btc into fee but I didn't actually add them up.
49 2013-01-29 01:29:23 <petertodd> gmaxwell: damn, good thing it was just 1BTC
50 2013-01-29 01:29:34 <gmaxwell> well it wouldn't have been much more because I did look.
51 2013-01-29 01:30:08 <MC1984> what the hell is taint analysis anyway
52 2013-01-29 01:30:57 <MC1984> just tracing where a coin has been?
53 2013-01-29 01:31:09 <upb> it has nothing to do with coins specifically
54 2013-01-29 01:49:14 <MC1984> im not sure whats going on in that thread
55 2013-01-29 01:49:23 <MC1984> but it seems suitably harebrained
56 2013-01-29 01:50:15 <doublec> mr 40k btc was brave. I'd be too worried about making a typo and sending all the coins into the void
57 2013-01-29 01:52:49 <MC1984> did he really do a raw txn with 40,000 btc
58 2013-01-29 02:02:30 <gmaxwell> doublec: I did at least double check it for him.
59 2013-01-29 02:02:43 <gmaxwell> (thus the aformentioned trembling fingers)
60 2013-01-29 02:02:52 <gmaxwell> having a single txout of that value is a little crazy.
61 2013-01-29 02:07:24 <gmaxwell> https://bitcointalk.org/index.php?topic=139581.msg1486774#msg1486774 < I posted 10 more txouts, which are now confirmed... feel free to join in the fun.
62 2013-01-29 02:12:51 <MC1984> could you briefly explain what youre doing as if to a child
63 2013-01-29 02:13:04 <MC1984> it seems interesting but im too tired to parse your post
64 2013-01-29 02:13:41 <nanotube> MC1984: "go to sleep, you're too young for this".
65 2013-01-29 02:13:43 <nanotube> how's that? :)
66 2013-01-29 02:13:58 <MC1984> thats probably appropriate
67 2013-01-29 02:14:10 <nanotube> ?????????
68 2013-01-29 02:17:10 <gmaxwell> MC1984: People assume that if a transaction spends coins that were sent to address A and B that A and B are the same person.
69 2013-01-29 02:17:50 <gmaxwell> MC1984: this is commonly true, but not always. You and I can provide coins to a transation, and we each sign it... and yet you and I are not the same person.
70 2013-01-29 02:17:51 <nanotube> gmaxwell: s/to/from/ ? :)
71 2013-01-29 02:18:30 <gmaxwell> nanotube: well "previously sent to" there is no from in bitcoin??? (and this is an example of why prior to is not from: who is the from on the transactions we're creating in that thread?)
72 2013-01-29 02:19:18 <nanotube> well, in that case, "to address a and b, and then subsequently used in the same transaction" ?
73 2013-01-29 02:19:43 <gmaxwell> MC1984: There are real and significant uses for this. Say nanotube promises to post a picture of a shoe on his head for 1 BTC. You and I both want the picture, so we can cooperate to write a single txn that pays nanotube 0.5 from each of us... and no risk that the other guy backs out.
74 2013-01-29 02:19:44 <MC1984> this is using the multisig stuff right, which only works via rawtx currently
75 2013-01-29 02:20:01 <nanotube> that said... if a signature is required from address X to validate the transaction, i'd say that part of the transaction is "from" that address.
76 2013-01-29 02:20:03 <gmaxwell> MC1984: No multisig, it's using 'half signed' transactions.
77 2013-01-29 02:20:23 <gmaxwell> nanotube: and when the outputs don't neatly factor? which bit is from what? :P
78 2013-01-29 02:20:41 <nanotube> oh, i'm not about to say /how much/ of the tx is from which address. :)
79 2013-01-29 02:20:44 <nanotube> but at least /some/ of it is.
80 2013-01-29 02:21:06 <CodeShark> ?!?
81 2013-01-29 02:21:12 <gmaxwell> MC1984: A transation has one signature per coin it is spending (input). If you and I cooperate to write a transaction, we can each only sign for our own inputs.
82 2013-01-29 02:22:13 <gmaxwell> MC1984: so I tell you a coin of mine we're going to spend, and you write a transaction that spends it, spends one or more of yours, and sends funds to nanotube and optional change back to either or both of us.
83 2013-01-29 02:22:27 <MC1984> and youre doing this purely to show the armchair bitcoin detectives how dumb they are
84 2013-01-29 02:22:32 <gmaxwell> Then you sign for your coins, and give me the half signed txn, and I sign for my coins... then its complete and I can annouce it.
85 2013-01-29 02:22:48 <gmaxwell> MC1984: also to teach people about bitcoin, the raw transactions API, and because it's fun.
86 2013-01-29 02:23:06 <MC1984> fun comes last lol
87 2013-01-29 02:23:10 <gmaxwell> It also get people thinking about neat possiblities. Like creating the kind of joint payment I just described.
88 2013-01-29 02:24:05 <gmaxwell> Plus I wanted to make the "I taint rich!" pun.
89 2013-01-29 02:24:42 <nanotube> iow, so many reasons to do it, and none not to. :)
90 2013-01-29 02:25:45 <MC1984> id try it but the liklihood of me fucking it up approaches 1
91 2013-01-29 02:26:08 <petertodd> I'll go in a joint for about 5BTC with someone else with unknown outputs
92 2013-01-29 02:26:20 <petertodd> ie, we both put in 5BTC, and out comes 10BTC to various addrs
93 2013-01-29 02:26:29 <petertodd> msg me in private
94 2013-01-29 02:26:49 <MC1984> isnt this coin mixing?
95 2013-01-29 02:26:55 <petertodd> bingo
96 2013-01-29 02:27:04 <petertodd> figure I'll add gmaxwell into it as well
97 2013-01-29 02:27:13 <gmaxwell> MC1984: yes, well, kinda. If its private it is??? but its trustless mixing??? no risk of theft when done right.
98 2013-01-29 02:27:22 <MC1984> but only druggies do coin mixing
99 2013-01-29 02:27:34 <petertodd> yeah, right out in public
100 2013-01-29 02:29:05 <MC1984> you cant take my coins because once ive signed my end, any changes invalidate the whole thing right
101 2013-01-29 02:29:38 <petertodd> exactly
102 2013-01-29 02:29:59 <MC1984> why the hooha over multisig if you can do this al along
103 2013-01-29 02:30:13 <petertodd> we privately agree on a list of txouts and txins
104 2013-01-29 02:30:29 <petertodd> for any given txout you sitll only need one private key to spend it
105 2013-01-29 02:30:52 <petertodd> it's just that once I sign a whole transaction, I'm basically signing "this set of txins go to this set of txouts"
106 2013-01-29 02:34:51 <gmaxwell> MC1984: multisig creates a single output that take multiple people to spend. This has multiple people make a single transaction that spends multiple outputs
107 2013-01-29 02:35:54 <MC1984> oh yeah
108 2013-01-29 02:36:26 <MC1984> mite b cool if these funky tx types had some official GUI rep instead of pasting hex around
109 2013-01-29 02:38:07 <petertodd> also people can email me to set this up if you don't trust freenode...
110 2013-01-29 02:38:31 <gmaxwell> MC1984: getting them GUIs involves knowing how people would use them.
111 2013-01-29 02:38:46 <gmaxwell> Someone go swap with petertodd. :)
112 2013-01-29 02:39:00 <petertodd> actually I already got two responses
113 2013-01-29 02:39:07 <petertodd> but more is good!
114 2013-01-29 02:40:08 <lianj> the manual mixmaster?
115 2013-01-29 02:40:21 <petertodd> no, that's what I call myself in da club
116 2013-01-29 02:41:27 <gmaxwell> hm. calling oneself the "taint master" might garnish entirely the wrong sorts of email responses.
117 2013-01-29 02:42:24 <petertodd> yes, quite possibly...
118 2013-01-29 02:42:50 <CodeShark> lol @ taint master
119 2013-01-29 02:45:56 <Diablo-D3> the.... oh boy.
120 2013-01-29 02:46:08 <petertodd> alright, last call, no more takers? we're at 4 including myself and gmaxwell
121 2013-01-29 02:46:38 <CodeShark> so what's the proposition?
122 2013-01-29 02:47:19 <CodeShark> we're all going to sign a single transaction, but different inputs?
123 2013-01-29 02:47:57 <petertodd> yes, 4 inputs, 4 outputs
124 2013-01-29 02:48:08 <petertodd> only I know what was what
125 2013-01-29 02:48:44 <CodeShark> to whom do the outputs belong?
126 2013-01-29 02:48:54 <lianj> arent there good automatic mixing services?
127 2013-01-29 02:49:01 <petertodd> everyone picks an output
128 2013-01-29 02:49:03 <jgarzik> lianj: not really
129 2013-01-29 02:49:08 <lianj> aw
130 2013-01-29 02:49:21 <petertodd> and they only sign if they are happy with the outputs list
131 2013-01-29 02:49:22 <jgarzik> lianj: good mixing requires good volume from multiple parties
132 2013-01-29 02:49:41 <jgarzik> lianj: and who trusts an anonymous mixing service that much, to send 1,000 BTC (for example) into the ether?
133 2013-01-29 02:49:48 <lianj> right, but lots of coins get stolen, there should be enough who need it
134 2013-01-29 02:50:00 <lianj> good point :D
135 2013-01-29 02:50:07 <lianj> wait, i got an idea
136 2013-01-29 02:50:10 <lianj> :P
137 2013-01-29 02:50:36 <CodeShark> money laundering done right? :)
138 2013-01-29 02:50:43 <petertodd> privacy
139 2013-01-29 02:50:50 <CodeShark> oh, right... :P
140 2013-01-29 02:50:50 <gmaxwell> petertodd: which of mine are you using? I'd suggest not using 0 as thats the first on other people will use.
141 2013-01-29 02:50:57 <CodeShark> privacy is better PR
142 2013-01-29 02:51:03 <petertodd> bitcoin has no privacy unless you work at it, it's natual to expect people to want to keep their competitors from knowing how much they have
143 2013-01-29 02:51:12 <petertodd> I was gonna pick #6
144 2013-01-29 02:51:38 <gmaxwell> CodeShark: see my comments on https://bitcointalk.org/index.php?topic=139581.msg1486925#msg1486925
145 2013-01-29 02:52:38 <gmaxwell> petertodd: The example I use is "no one wants their inlaws asking how they're going to get grandkids when you're buying contraception" (funny, luke doesn't like that one). Casual privacy matters.
146 2013-01-29 02:53:20 <lianj> jgarzik: maybe the best right now is to travel multiple oneline wallets
147 2013-01-29 02:53:43 <lianj> depending on what they do in their backend
148 2013-01-29 02:53:56 <petertodd> gmaxwell: that's a good one
149 2013-01-29 02:53:58 <jgarzik> Baby Got Backend
150 2013-01-29 02:58:35 <CodeShark> there could be a side network that propagates partially signed transactions
151 2013-01-29 02:58:54 <CodeShark> or allows parties to add new inputs and outputs to the same transaction
152 2013-01-29 02:59:14 <CodeShark> how would you make that collaborative and not subject to DoS?
153 2013-01-29 02:59:45 <CodeShark> and how could you permute the outputs so that only the participants know which is which?
154 2013-01-29 02:59:53 <CodeShark> or better yet, so the participants only know which output is theirs
155 2013-01-29 03:00:29 <CodeShark> it would be cool to be able to do mixing in a completely decentralized fashion
156 2013-01-29 03:01:01 <gmaxwell> petertodd: got something for me to sign yet?
157 2013-01-29 03:01:22 <gmaxwell> (I don't need to be last)
158 2013-01-29 03:01:44 <MC1984> CodeShark people have discussed it before
159 2013-01-29 03:02:09 <MC1984> maybe a sidechain somehow
160 2013-01-29 03:02:20 <MC1984> disappointed nothing really useful came out of merged mining
161 2013-01-29 03:02:30 <gmaxwell> CodeShark: you can make it not subject to DOS by making initial participation somewhat costly, and DOS gets you blacklisted.
162 2013-01-29 03:03:02 <gmaxwell> and you can make it blinded by a complicated token procedure. :P
163 2013-01-29 03:03:14 <gmaxwell> but I don't know how to make it blinded and completely decenteralized.
164 2013-01-29 03:04:14 <gmaxwell> CodeShark: basically??? a 'server' starts a round and accepts 1 btc txid from permitted users. As users submit IDs they also give the server a blinded token which the server signs.
165 2013-01-29 03:04:45 <gmaxwell> CodeShark: then they reconnect anonymously (so the server doesn't know who is who) and exchange their unblineded tokens for slots in the txouts.
166 2013-01-29 03:05:09 <CodeShark> that could work
167 2013-01-29 03:05:12 <gmaxwell> CodeShark: well all are gathered the server posts it and people connect again to sign their inputs. (back under their accounts)
168 2013-01-29 03:05:26 <gmaxwell> And if someone fails to sign they get blacklisted.
169 2013-01-29 03:05:54 <gmaxwell> but that kind of complexity isn't needed for something to improve privacy a bit.
170 2013-01-29 03:06:11 <CodeShark> blacklisted? sounds difficult to blacklist someone
171 2013-01-29 03:06:19 <gmaxwell> CodeShark: I consulted on and beta tested a site that did all of this, dunno what happened to it.
172 2013-01-29 03:06:26 <gmaxwell> (it was never made public)
173 2013-01-29 03:06:52 <gmaxwell> CodeShark: it's trivial.. to join in the fun you have to pay some fee. If you're blacklisted you abandon the fee.
174 2013-01-29 03:07:28 <gmaxwell> You can get initial users by having a free for all initially, and grandfather established users.
175 2013-01-29 03:08:20 <CodeShark> but if the whole point is privacy, you can only punish defectors within the actual round in which they participate
176 2013-01-29 03:08:36 <gmaxwell> CodeShark: the point is privacy of outputs, not inputs.
177 2013-01-29 03:08:47 <gmaxwell> if the inputs were already private, no need for the mixer.
178 2013-01-29 03:09:04 <gmaxwell> The outputs are private by virtue of blinding with the chaum tokens.
179 2013-01-29 03:09:24 <gmaxwell> and the identity is nothing more than 'sent bitcoins to some address' and connected over tor.
180 2013-01-29 03:10:11 <CodeShark> could it be done without the use of a "server"?
181 2013-01-29 03:10:35 <CodeShark> i.e. anyone can send out a proposal and others can join in until the slots are full
182 2013-01-29 03:10:50 <gmaxwell> kinda. How about using a group blinded signature.
183 2013-01-29 03:11:13 <gmaxwell> CodeShark: the hard part is making it so only participants can get outputs, but no one knows input->output mapping.
184 2013-01-29 03:12:06 <gmaxwell> Here is how a group blinded signature would work. Everyone comes up with an key. Everyone puts up some coins. Each user blinds a message specifying their output address and publically puts the blinded message up for group blindsigning by everyone.
185 2013-01-29 03:12:35 <gmaxwell> Then the messages are unblinded and resubmited anonymously.. and everyone can see that they're signed by everyone.
186 2013-01-29 03:12:49 <gmaxwell> ... I think I've seen papers on group blind signing, I've never seen an implementation.
187 2013-01-29 03:12:54 <gmaxwell> But that would get you serverless.
188 2013-01-29 03:14:04 <gmaxwell> Doing the anti-DOS is a bit tricker. How do you convince a new participant that Alice is naughty and doesn't complete the signatures? Not unsolvable but a lot of code to construct and check the proofs.
189 2013-01-29 03:18:08 <CodeShark> could it be done so that if any of the participants fail to sign after a certain number of blocks, their contribution gets distributed amongst the participants that did sign?
190 2013-01-29 03:19:50 <gmaxwell> CodeShark: not usefully, there is the crazy I only care about the matching output sigtype.... but thats not what you want for anonymity.
191 2013-01-29 03:19:59 <gmaxwell> CodeShark: but you'd make it all automated, so it would just retry on failure.
192 2013-01-29 03:20:37 <gmaxwell> the only reason it couldn't try a dozen times in a minute is that you'd want to delay the reconnection to submit unblinded tokens to thwart traffic analysis.
193 2013-01-29 03:21:33 <gmaxwell> though god knows there is probably some awesome cryptographic shuffle you could do if you could make the unblinding homorphic.
194 2013-01-29 03:25:32 <CodeShark> it's a fascinating problem and it's hurting my brain :p
195 2013-01-29 03:26:32 <CodeShark> what's that idea called where you encrypt something in a way where it can only be decrypted at some point in the future?
196 2013-01-29 03:26:33 <jgarzik> bah, a new warning?
197 2013-01-29 03:26:35 <jgarzik> main.cpp:97:13: warning: ???bool IsFromMe(CTransaction&)??? defined but not used [-Wunused-function]
198 2013-01-29 03:26:47 <CodeShark> yeah, I've been noticing that one, too, jgarzik :)
199 2013-01-29 03:26:54 <gmaxwell> CodeShark: timelock
200 2013-01-29 03:26:56 <CodeShark> if it bothers you just comment out that line
201 2013-01-29 03:27:35 <jgarzik> CodeShark: oh, much more violence is needed than just that.
202 2013-01-29 03:29:49 <Luke-Jr> #if 0
203 2013-01-29 03:30:10 <CodeShark> all that code will be undergoing hardcore surgery after 0.8.0 :)
204 2013-01-29 03:30:55 <jgarzik> at least it only appears once
205 2013-01-29 03:31:16 <jgarzik> if it appeared once per main.h, say, that would be different
206 2013-01-29 03:31:32 <CodeShark> gmaxwell: so if you use some sort of timelock where everyone signs to an output that can be claimed only after a certain amount of time?
207 2013-01-29 03:33:33 <CodeShark> and the actual transaction doublespends it - but only one or the other is propagated on the real p2p network
208 2013-01-29 03:33:40 <CodeShark> or something like that :p
209 2013-01-29 03:34:03 <CodeShark> basically, either everyone signs and the original timelocked transaction is voided - or someone fails to sign and then someone else can claim it
210 2013-01-29 03:34:47 <CodeShark> hmmm....it's way subtler than that
211 2013-01-29 03:35:21 <CodeShark> it would have to be impossible to claim the output by any other means than either the timelocked transaction or the joint transaction
212 2013-01-29 03:42:14 <gmaxwell> CodeShark: I think it's easier to just use a non-interactive zkp in the protocol and so you can prove if anyone cheats and then show that proof to any new commers and just blacklist cheaters. ... and restart when it fails.
213 2013-01-29 03:43:08 <CodeShark> what's to stop cheaters from just reconnecting under a different identity?
214 2013-01-29 03:43:36 <gmaxwell> CodeShark: a fidelity bond, of course.
215 2013-01-29 03:43:48 <CodeShark> where can I read up more on this fidelity bond idea?
216 2013-01-29 03:43:53 <CodeShark> I missed those convos :)
217 2013-01-29 03:44:34 <gmaxwell> CodeShark: the idea is simple: You provably give away some coin to mining fees. Now the key which did this is a fidelity bond (you can add some rules for transfering ownership of said bond??? if you like)
218 2013-01-29 03:45:16 <gmaxwell> Now that you have a bond you can either behave... or if you misbehave the people who wittness will construct a proof, and anyone who sees that proof will consider your fidelity bond worthless.
219 2013-01-29 03:46:04 <gmaxwell> For something like this the bond could just be donating to a charity and not mining fees... the only risk would be the charity donating to themselves forever to blockaid you.
220 2013-01-29 03:46:48 <CodeShark> not sure I follow
221 2013-01-29 03:47:02 <CodeShark> why do you need to give anything away?
222 2013-01-29 03:47:38 <CodeShark> and how is this fidelity bond associated with other transactions of yours?
223 2013-01-29 03:49:35 <gmaxwell> The idea is to use the scarcity of funds to make a scarce identity. You give away funds, and prove that you did it for the purpose of making a fidelity bond. (a key annointed with the special scarcity of being a fidelity bond) This key is now valuable because you can use it to gain access to whatever requires you to have a fidelity bond.
224 2013-01-29 03:50:11 <gmaxwell> If you act unfaithful (break the rules) people will publish proofs and you'll lose your bond (everyone will ignore it). If you want a new bond you'll have to give away more coin.
225 2013-01-29 03:50:44 <gmaxwell> If you get tired of your fidelity bond, you could sell it if the defintion of one allows it to be transfered.
226 2013-01-29 03:51:06 <CodeShark> so you basically attach an identity to a particular key and then include that key in your transactions to mark them as yours?
227 2013-01-29 03:51:10 <gmaxwell> If it's any consolation when petertodd posted on this I didn't really get it either. I guess I'm not good at explaining it.
228 2013-01-29 03:51:29 <CodeShark> yea, I totally don't get it - lol
229 2013-01-29 03:52:11 <CodeShark> I'm not even sure what problem fidelity bonds are trying to solve in the first place
230 2013-01-29 03:52:14 <Luke-Jr> if it helps, neither do I ;)
231 2013-01-29 03:52:44 <gmaxwell> Lets step back for a minute. Say we have a forum where spam is a problem. We want to be anonymous but want to ban spammers.
232 2013-01-29 03:52:57 <gmaxwell> Say it's a decenteralized forum too, for fun.
233 2013-01-29 03:53:16 <CodeShark> like, say, bitcoin-otc :)
234 2013-01-29 03:53:24 <CodeShark> but with no moderators
235 2013-01-29 03:53:29 <gmaxwell> We require every post be signed with a key that has given away at least 1 BTC and isn't on the blacklist.
236 2013-01-29 03:53:49 <gmaxwell> This is a simple machine rule... software enforces it no problem.
237 2013-01-29 03:53:50 <CodeShark> ok
238 2013-01-29 03:53:59 <CodeShark> still with you
239 2013-01-29 03:54:11 <gmaxwell> Now say you spam. It's obvious to everyone that its spam... and so someone publishes a notice with your signed copy of your spam.
240 2013-01-29 03:54:29 <gmaxwell> And when users show up at the forum they get the notice and say.. oh indeed.. they key spammed. I'll ignore it forever now.
241 2013-01-29 03:54:55 <gmaxwell> (of course, for spam consensus might be hard?????but for digital fiance we can make indisputable criteria)
242 2013-01-29 03:55:05 <gmaxwell> So the spammer must constantly spend 1 BTC per spam sent.
243 2013-01-29 03:55:12 <gmaxwell> But honest users just have to spend 1 BTC once.
244 2013-01-29 03:55:20 <CodeShark> ok, I sorta get it
245 2013-01-29 03:56:13 <gmaxwell> and, say we also allow people to transfer their bondedness to another key??? e.g. they want to leave the forum and want their 1 BTC back.. so they sell their bond to someone who wants in maybe for .9 btc so that person doesn't have to give away coin.
246 2013-01-29 03:56:30 <gmaxwell> so even if you're ready to quit??? it's in your interest to preserve your bond's reputation.
247 2013-01-29 03:57:28 <CodeShark> miners could still cheat the system, no?
248 2013-01-29 03:57:32 <gmaxwell> What petertodd proposes doing is having bitcoin banks which have big fidelity bonds ??? ones of potentially thousands of btc. And the client software for the bank will never let deposts go higher than the value of the bond. And if the bank ever cheats??? won't process a transaction.. someone publishes proof and the bank's bond is destroyed.
249 2013-01-29 03:57:41 <gmaxwell> CodeShark: petertodd solved that using locktime.
250 2013-01-29 03:57:58 <gmaxwell> You mine a transaction which contains nested inside it a high fee child transaction with a locktime in the future.
251 2013-01-29 03:58:15 <gmaxwell> Then all miners know about this locked transaction... and you can't control who mines it.
252 2013-01-29 03:58:22 <CodeShark> right
253 2013-01-29 03:58:29 <gmaxwell> for a big bond you might require it be composed of multiple smaller ones in any case.
254 2013-01-29 03:59:16 <CodeShark> interesting
255 2013-01-29 03:59:27 <gmaxwell> if you don't need that much security (e.g. for chat or a mixer) then perhaps you'd just use a payments to a charity reconized by the whole community instead of mining fees. (mining fees are kind of like a distributed charity for network security) Would be less secure.. but people might find that more rewarding than just mining fees.
256 2013-01-29 03:59:57 <CodeShark> ripe for corruption, though :)
257 2013-01-29 04:00:04 <CodeShark> charities could be bought and manipulated
258 2013-01-29 04:00:12 <gmaxwell> well, depends on what you're doing??? for banks I agree.
259 2013-01-29 04:00:31 <gmaxwell> For chatroom access? who is going to take over a major charity to spam a chatroom more cheaply? :P
260 2013-01-29 04:01:16 <CodeShark> erection pill manufacturers and nigerian princes :p
261 2013-01-29 04:03:11 <CodeShark> never underestimate the motivation and resolve of scammers
262 2013-01-29 04:04:15 <CodeShark> at least if you sacrifice to mining, it's up for grabs
263 2013-01-29 04:05:01 <CodeShark> in principle those funds get distributed equitably amongst all miners
264 2013-01-29 04:05:10 <CodeShark> so it's impossible to manipulate them
265 2013-01-29 04:26:18 <CodeShark> you can also just throw away bitcoins by sending them to the all zero pubkey :)
266 2013-01-29 04:26:46 <CodeShark> or some specific pubkey
267 2013-01-29 04:26:57 <petertodd> or a null txout with sighash none
268 2013-01-29 04:27:05 <petertodd> so the txout is replacable
269 2013-01-29 04:27:25 <petertodd> it's the smallest possible nested tx, and it happens to be valid
270 2013-01-29 04:28:17 <gmaxwell> A little moral hazard there at least for big bonds: creates an incentive to fork the chain.
271 2013-01-29 04:29:02 <petertodd> That worries me...
272 2013-01-29 04:29:24 <CodeShark> require bonds to have a certain number of confirmations before they are accepted
273 2013-01-29 04:29:26 <petertodd> It'd be nice if bitcoin had a mechanism where the next n miners could get a share of the tx fee.
274 2013-01-29 04:29:38 <petertodd> CodeShark: mandatory
275 2013-01-29 04:30:04 <petertodd> CodeShark: double-spends are just as much of a problem as anywhere else
276 2013-01-29 04:30:11 <CodeShark> sure
277 2013-01-29 04:30:58 <gmaxwell> petertodd: you can make that explicitly, just with a chain of transactions locked one after another.
278 2013-01-29 04:31:05 <gmaxwell> This can be used to pay people to make forks. :(
279 2013-01-29 04:31:16 <CodeShark> hah
280 2013-01-29 04:31:18 <CodeShark> indeed
281 2013-01-29 04:31:47 <CodeShark> perhaps miners can be corrupted after all
282 2013-01-29 04:32:03 <petertodd> gmaxwell: Ugh, that one is nasty...
283 2013-01-29 04:32:45 <petertodd> I suspect going forward we're really going to find that 6 confs isn't enough.
284 2013-01-29 04:33:21 <CodeShark> or we'll have to use trust mechanisms outside the block chain
285 2013-01-29 04:35:04 <gmaxwell> petertodd: It's not enough now??? I mean if you want to be clear eyed about it... a pool with 30% hash power or whatever could do whatever for _hours_ if they were hacked.
286 2013-01-29 04:35:41 <gmaxwell> And these pools are hosted on random inexpensive hosting. Their operation is typical one or two persons part-time jobs.
287 2013-01-29 04:36:22 <gmaxwell> And when you hack one you even get 1000 btc to try your doublespending lottery with.
288 2013-01-29 04:36:26 <gmaxwell> but ::shrugs::
289 2013-01-29 04:36:45 <gmaxwell> small parties are not likely to be a target, and large ones eat it as a cost of doing business.
290 2013-01-29 04:38:03 <gmaxwell> I thought it would be neat to set the required confirms based on the txn value and a user set "how much hashpower I think an attacker could get" knob... but then I realized you don't need to use the txn value, you need to use the full value of all txn in the block, as they could all be doublespend attacks. :(
291 2013-01-29 04:39:08 <gmaxwell> and this ends up resulting in telling you that you need 12-15 confirms to make an attack negative EV on the current network.. this also got worse because of the subsidy drop: the cost of failure is lower.
292 2013-01-29 04:39:09 <petertodd> Given that blocks are easily transfering a quarter million USD each...
293 2013-01-29 04:39:52 <petertodd> I'm increasingly thinking keeping the subsidy fixed would have been better; it at least gives you a number to reason about.
294 2013-01-29 04:40:22 <petertodd> Reminds me: do we know if all the new ASIC hardware is P2Pool compatible?
295 2013-01-29 04:40:35 <gmaxwell> constant inflation is distorting: if you do that then the value of btc can't frefloat to its optimal value without dragging the rewards of mining along with it.
296 2013-01-29 04:40:45 <gmaxwell> petertodd: it would be hard for it not to be.
297 2013-01-29 04:41:03 <petertodd> Well, the ugly part about constant inflation, is constant reward is *not* constant inflation of the money supply.
298 2013-01-29 04:41:13 <gmaxwell> that stuff will complete a nonce range per second or more... so even if it's like the BFL things and can't abort a nonce search, it wouldn't matter.
299 2013-01-29 04:41:24 <petertodd> Oh, yeah, good point...
300 2013-01-29 04:41:52 <petertodd> I point my BFL single at eligius right now, but I'd consider running p2pool otherwise.
301 2013-01-29 04:43:08 <gmaxwell> maybe they'll OSS those bitstreams once the ASIC are out. ... one could hope.
302 2013-01-29 04:43:36 <petertodd> Just telling us how to hook up Xilinx would be better than nothing.
303 2013-01-29 04:56:44 <ThomasV> gmaxwell: any news concerning bip32?
304 2013-01-29 05:14:30 <CodeShark> lol - are we going to break 20?
305 2013-01-29 05:15:45 <SomeoneWeird> we're going to break 200
306 2013-01-29 05:15:55 <CodeShark> what's the ETA on that
307 2013-01-29 05:15:56 <CodeShark> ?
308 2013-01-29 05:16:11 <SomeoneWeird> no idea
309 2013-01-29 05:27:51 <wumpus> sipa: I suppose it should work as long as you provde MODAL flag?
310 2013-01-29 05:30:55 <wumpus> sipa: after all that's how InitError/InitWarning etc work, if they're broken that's a big thing
311 2013-01-29 05:38:48 <CodeShark> sipa.sleep(250000);
312 2013-01-29 05:42:49 <SomeoneWeird> lols
313 2013-01-29 06:03:56 <wumpus> hehe
314 2013-01-29 06:04:06 <gmaxwell> 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb
315 2013-01-29 06:04:31 <Luke-Jr> gmaxwell: having fun? :p
316 2013-01-29 06:05:53 <gmaxwell> Yes!
317 2013-01-29 06:06:57 <Luke-Jr> me too
318 2013-01-29 06:35:04 <gmaxwell> You'd think that with the subsidy at 25 now I'd stop freaking out when I accidentally switch terminals and listtransactions a testnet node and see a wall of 50 coin generate txn.. but no.
319 2013-01-29 06:35:37 <Luke-Jr> heh
320 2013-01-29 06:47:31 <muhoo> i'm intrigued by this multi-signing mixing thing. isn't it basically kickstarter?
321 2013-01-29 06:48:48 <muhoo> or fundable, back in the day.
322 2013-01-29 06:48:51 <muhoo> taintstarter
323 2013-01-29 06:48:54 <gmaxwell> muhoo: you could use it that way, if you like.
324 2013-01-29 06:52:16 <muhoo> what's that number, 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb ? is that a tx?
325 2013-01-29 06:52:46 <grau> gmaxwell: that I taint rich thread of you is genuine. I am bit afraid that such mixer will be the next SD.
326 2013-01-29 06:54:08 <gmaxwell> grau: It isn't a new idea??? and done well it reduces transactions. The bigger concern I have with SD is the UTXO bloat, and this kind of use is no big hazard for it.
327 2013-01-29 06:54:16 <gmaxwell> muhoo: it's a txid yes.
328 2013-01-29 06:54:45 <muhoo> it looks like it hasn't been seen on the network (at least blockexplorer has no clue of it)
329 2013-01-29 06:55:11 <gmaxwell> It has 12 confirmations now.
330 2013-01-29 06:58:09 <grau> Genuine is that you just created a public address for yourself that can be associated with huge amounts while you can claim it is not yours.
331 2013-01-29 07:00:25 <gmaxwell> I wondered when someone would suggest that!
332 2013-01-29 07:00:57 <gmaxwell> But I have nothing to gain from that, as I'd just not mix huge amounts with my known addressess??? if I had huge amounts, which I don't. :P
333 2013-01-29 07:01:14 <grau> sure :)
334 2013-01-29 07:07:07 <muhoo> 40kbtc? holy crap
335 2013-01-29 07:07:27 <muhoo> in ukraine, says blockchain.info. why am i not surprised by that
336 2013-01-29 07:08:04 <gmaxwell> You should not be surprised by that because like a sane person, I block blockchain.info's snoppy nodes.
337 2013-01-29 07:08:16 <gmaxwell> (I announced that transaction)
338 2013-01-29 07:11:36 <SomeoneWeird> heh
339 2013-01-29 07:18:48 <muhoo> ah, i guess that's a tor exit node then
340 2013-01-29 07:19:05 <gmaxwell> or just some random bitcoin node.
341 2013-01-29 07:19:26 <gmaxwell> because I block them they'll report it as coming from some random peer of mine.
342 2013-01-29 07:19:49 <muhoo> how do you block them?
343 2013-01-29 07:20:13 <SomeoneWeird> magik
344 2013-01-29 07:20:38 <gmaxwell> They're on 91.203.74.0/24 so I just firewall off that network from reaching my bitcoin nodes.
345 2013-01-29 07:21:28 <gmaxwell> if you care at all about privacy you should run bitcoin over tor though.
346 2013-01-29 07:21:36 <gmaxwell> I do that too.
347 2013-01-29 07:22:14 <muhoo> i'm confused as to how they can tell what ip address a transaction was originally broadcast from
348 2013-01-29 07:22:27 <muhoo> is the address encoded in the tx?
349 2013-01-29 07:22:32 <SomeoneWeird> he's just blocking peering with them
350 2013-01-29 07:22:46 <muhoo> oh. but, they can't peer with EVERYONE can they?
351 2013-01-29 07:23:06 <SomeoneWeird> they can try
352 2013-01-29 07:23:09 <SomeoneWeird> lol
353 2013-01-29 07:23:14 <muhoo> do they really do that? wow.
354 2013-01-29 07:23:32 <Luke-Jr> I do too.
355 2013-01-29 07:23:35 <Luke-Jr> <.<
356 2013-01-29 07:23:42 <SomeoneWeird> iirc
357 2013-01-29 07:23:42 <SomeoneWeird> well you can see how many nodes theyre connected to at the bottom of the page
358 2013-01-29 07:23:52 <Luke-Jr> "connections" : 534,
359 2013-01-29 07:24:45 <muhoo> oh. crap http://blockchain.info/connected-nodes
360 2013-01-29 07:26:45 <SomeoneWeird> seewotimean
361 2013-01-29 07:26:58 <muhoo> jeebus http://blockchain.info/ip-address/74.101.135.64 ... not much anonmymity there.
362 2013-01-29 07:27:26 <SomeoneWeird> is there a limit to login requests over RPC ?
363 2013-01-29 07:29:45 <muhoo> hahahaa, and it's total bullshit too!
364 2013-01-29 07:29:53 <gmaxwell> muhoo: thats why I blocked them, initially they had a bunch of connections to my network.. waste of resources just for the purpose of degrading privacy.
365 2013-01-29 07:30:16 <muhoo> i looked up the ip address of my node, and it shows a shit-ton of transactions that i never transmitted, because i have no wallet on that box!
366 2013-01-29 07:31:03 <muhoo> ACTION fires up iptables now
367 2013-01-29 07:32:06 <muhoo> gmaxwell: thanks for that tip
368 2013-01-29 07:33:23 <muhoo> and... done: sudo iptables -A INPUT -s 91.203.74.0/24 -j DROP
369 2013-01-29 07:33:35 <muhoo> :-P
370 2013-01-29 07:33:44 <Luke-Jr> REJECT is nicer than DROP
371 2013-01-29 07:34:19 <SomeoneWeird> fuck being ncie
372 2013-01-29 07:34:21 <SomeoneWeird> nice
373 2013-01-29 07:34:22 <SomeoneWeird> lol
374 2013-01-29 07:34:30 <gmaxwell> -j tarpit
375 2013-01-29 07:34:36 <muhoo> no, let them have their connections hang in SYN_WAIT
376 2013-01-29 07:35:02 <gmaxwell> http://www.netfilter.org/projects/patch-o-matic/pom-external.html#pom-external-TARPIT
377 2013-01-29 07:35:35 <gmaxwell> but really, reject is fine.
378 2013-01-29 07:44:00 <muhoo> oh i see. the ip address was used by someone else. the transactions it shows are from a year ago. i just spun up this vps a month ago.
379 2013-01-29 07:50:47 <gmaxwell> lol:
380 2013-01-29 07:50:48 <gmaxwell> "address" : "1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB",
381 2013-01-29 07:50:48 <gmaxwell> "amount" : -1.00000000,
382 2013-01-29 07:50:48 <gmaxwell> "category" : "send",
383 2013-01-29 07:50:48 <gmaxwell> "fee" : 50000.31337000,
384 2013-01-29 07:51:46 <gmaxwell> I think I enjoy laughing at that behavior too much to fix it.
385 2013-01-29 08:03:59 <SomeoneWeird> oh that seems legit gmaxwell
386 2013-01-29 11:17:08 <pisto> hello. in FileCommit (utils.cpp), is the fsync() call really needed? In my opinion it just slows down everything. I'm synchronizing with the blocks chain, and my system is almost unresponsive
387 2013-01-29 11:17:35 <sipa> pisto: which code version?
388 2013-01-29 11:18:01 <pisto> v0.7.2.0-g32a928e-beta
389 2013-01-29 11:18:18 <sipa> you can change it into fdatasync, if necessary
390 2013-01-29 11:18:32 <sipa> which is around 2-3x faster
391 2013-01-29 11:18:39 <sipa> in 0.8 it will be fdatasync, and also called less frequently
392 2013-01-29 11:19:01 <sipa> disabling it may cause corruption in case of a system crash
393 2013-01-29 11:19:58 <pisto> well.. if the system crashes while fsyncing, you would still have troubles I guess
394 2013-01-29 11:21:03 <sipa> pisto: no, the fsync is to make sure the block data is present on disk before any index entry is written that links to it
395 2013-01-29 11:21:21 <sipa> pisto: so if the system crashes during the fsync you may end up with a partial block on disk, but it would just be redownloaded
396 2013-01-29 11:23:01 <sipa> of course, that's just theory, because in practice we hear a lot about the BDB database itself becoming corrupted when crashed
397 2013-01-29 11:23:15 <sipa> hopefully LevelDB is more resilient
398 2013-01-29 11:23:44 <SomeoneWeird> hopefully lol
399 2013-01-29 11:25:12 <sipa> well i personally never got my own BDB corrupted (except intentionally)
400 2013-01-29 11:25:23 <sipa> and the same is true for LevelDB, so i can't really compare
401 2013-01-29 11:25:34 <sipa> though from my understanding of LevelDB, it should be much less likely
402 2013-01-29 14:07:42 <BTCOxygen> jgarzik: hi
403 2013-01-29 14:08:06 <BTCOxygen> jgarzik: any news about your ASIC ?
404 2013-01-29 14:10:13 <jgarzik> BTCOxygen: read the thread "Avalon ASIC ships" thread on the forum, https://bitcointalk.org/index.php?topic=137534.0
405 2013-01-29 14:10:28 <jgarzik> My latest post is https://bitcointalk.org/index.php?topic=137534.msg1487020#msg1487020
406 2013-01-29 14:12:00 <sipa> jgarzik: lol, you seem to get that question kinda frequently :p
407 2013-01-29 14:20:00 <jgarzik> That's what happens when a large segment of the bitcoin forum community is teenagers with nothing but time on their hands
408 2013-01-29 14:20:11 <jgarzik> to troll and post on Internet forums ;p
409 2013-01-29 14:22:16 <Luke-Jr> jgarzik should send Avalon a bill <.<
410 2013-01-29 14:22:38 <jgarzik> Luke-Jr: I've pondered
411 2013-01-29 14:22:55 <jgarzik> I'm aggressively honest, and thus easily trolled into writing an honest review
412 2013-01-29 14:23:11 <Luke-Jr> heh
413 2013-01-29 14:23:40 <Luke-Jr> jgarzik: it would be epic if you politely declined to write a review ;)
414 2013-01-29 14:25:10 <pjorrit> why not make one up right now and review an imaginary brick in a box you just received
415 2013-01-29 14:26:15 <Luke-Jr> that wouldn't be honest
416 2013-01-29 14:26:18 <helo> osmotic (no plugs) zero-power (no hashrate) mining brick (literally a brick)
417 2013-01-29 14:29:43 <pjorrit> it just would make a ton of sense if you were a teenager with too much time on your hands
418 2013-01-29 14:50:00 <Luke-Jr> _floodWarning(now, "MerkleUpdate", [&]() { return (boost::format("Haven't updated the merkle tree in at least %d seconds! Is your server fast enough to keep up with your configured work queue minimums?") % (now - lastMerkleUpdate)).str(); });
419 2013-01-29 14:50:09 <Luke-Jr> I have to say, C++ syntax is getting as obfuscated as Perl..
420 2013-01-29 14:51:03 <v1rtex> Listener for "MTRED": Server sent: {"id":1,"error":null,"result":false}
421 2013-01-29 14:51:17 <v1rtex> is there anything I can do about that error?
422 2013-01-29 14:51:34 <v1rtex> or do I have to stop and start guiminer every time?
423 2013-01-29 14:52:33 <Luke-Jr> v1rtex: sounds like a guiminer bug
424 2013-01-29 14:52:38 <Luke-Jr> that's a pretty normal response
425 2013-01-29 14:52:52 <gmaxwell> Luke-Jr: is that what a C++ lambda looks like?
426 2013-01-29 14:52:58 <Luke-Jr> gmaxwell: yep
427 2013-01-29 14:53:06 <kjj> [&] ftw!
428 2013-01-29 14:53:31 <v1rtex> Luke-Jr: so I should probably use another miner, eh?
429 2013-01-29 14:53:35 <Luke-Jr> the & means to access external variables (now and lastMerkleUpdate) by reference
430 2013-01-29 14:53:39 <gavinandresen> is [&] C++11 syntax for an anonymous function?
431 2013-01-29 14:53:52 <Luke-Jr> v1rtex: depends on what the cause is; can't hurt to try
432 2013-01-29 14:54:00 <Luke-Jr> gavinandresen: right..
433 2013-01-29 14:54:43 <kjj> kinda funny to see C++ approaching Greenspun's Tenth Rule
434 2013-01-29 14:54:46 <gmaxwell> How do you specify the return type?
435 2013-01-29 14:55:34 <Luke-Jr> gmaxwell: it's implied by the return statement, or you can do: []->returntype(){???}
436 2013-01-29 14:55:50 <Luke-Jr> which totally doesn't fit with the rest of C++ IMO
437 2013-01-29 14:56:13 <gmaxwell> yea. Crazy. Type inference?
438 2013-01-29 14:56:21 <sipa> well, C++ does infer types already for subexpressions
439 2013-01-29 14:56:23 <sipa> that doesn'
440 2013-01-29 14:56:25 <gavinandresen> sipa: RE: deal with leveldb errors: how about a CResult utility class that wraps a bool result and an error string ?
441 2013-01-29 14:56:28 <sipa> t surprise anyone
442 2013-01-29 14:56:36 <Luke-Jr> gmaxwell: I *really* like 'auto' for iterators???
443 2013-01-29 14:57:35 <gmaxwell> sipa: yea, I suppose??? I find it odder to see it on a function.
444 2013-01-29 14:58:00 <sipa> Luke-Jr: how do you mean? there's such a nice charm to std::map<std::pair<bool, int64>, std::vector<std::string> >::const_iterator = mapBlah.begin();
445 2013-01-29 14:58:15 <Luke-Jr> I just wish there was a way to say: variableinstanceofsomeclass = reconstruct(); without specifying the whole class name again..
446 2013-01-29 14:58:39 <Luke-Jr> sipa: I mean I prefer: for (auto = mapBlah.begin(); auto != mapBlah.end(); ++auto)
447 2013-01-29 14:58:42 <Luke-Jr> err
448 2013-01-29 14:58:48 <sipa> Luke-Jr: i was being sarcasting :)
449 2013-01-29 14:58:50 <Luke-Jr> sipa: I mean I prefer: for (auto it = mapBlah.begin(); it != mapBlah.end(); ++it)
450 2013-01-29 14:58:58 <Luke-Jr> ???
451 2013-01-29 14:59:12 <sipa> sarcasting is a sarcastic way of doing a cast
452 2013-01-29 15:00:07 <sipa> gavinandresen: there's several problems with making it clean; first, leveldb.* doesn't depend on main and main not on leveldb and i want to keep it that way if possible
453 2013-01-29 15:00:45 <sipa> so that means that both leveldb and main would need to define an interface for passing errors, and txdb would convert between them
454 2013-01-29 15:02:04 <sipa> gavinandresen: i think the easiest thing to do right now, is actually not botherin with catching errors, and just let the unhandled leveldb exception cause an abort at the top level of the application
455 2013-01-29 15:02:14 <sipa> gavinandresen: it's a very unexpected thing to happen anyway
456 2013-01-29 15:02:37 <sipa> gavinandresen: i had to modify by hand (very quickly!) leveldb files during reindex to cause it
457 2013-01-29 15:04:07 <gavinandresen> sipa: mmm. third possibility would be a little result.h file that defined the "return a boolean plus some extra information" type
458 2013-01-29 15:04:43 <CodeShark> having to deal with errors at all levels of the call stack is annoying :)
459 2013-01-29 15:04:57 <gavinandresen> annoying, but usually the correct thing to do
460 2013-01-29 15:05:28 <gavinandresen> sipa: in any case, I'm ok with throwing an exception and letting it catch at the highest level, as long as errors at startup are reasonable.
461 2013-01-29 15:05:58 <sipa> gavinandresen: the problem to do things cleanly is mostly that main aka "the block/tx validation service" has no clearly defined interface - it's being called at various levels from several places
462 2013-01-29 15:06:29 <sipa> gavinandresen: with some refactoing (including the one CodeShark has started), we could have such an interface, and have the public methods of that interface do the catching of any errors that happen underneath
463 2013-01-29 15:06:53 <gavinandresen> ???. and returning an error plus some extra information about exactly what the error is?
464 2013-01-29 15:07:03 <sipa> for example
465 2013-01-29 15:07:22 <gavinandresen> okey dokey. I'll bang on your latest commit a little this morning
466 2013-01-29 15:08:03 <sipa> one thing i did notice during testing, is that with the decreased blocks-to-check, it is now possible to actually corrupt the database when you're early in the chain (say up to 160-170k)
467 2013-01-29 15:08:10 <sipa> because 288k blocks is so little data
468 2013-01-29 15:09:09 <sipa> eh, 288
469 2013-01-29 15:09:13 <sipa> when early in the chain
470 2013-01-29 15:13:32 <gavinandresen> I'm falling in love with clang/lldb ???.
471 2013-01-29 15:14:07 <denisx> gavinandresen: already installed xcode 4.6?
472 2013-01-29 15:14:46 <gavinandresen> denisx: yes, but I don't code in Xcode; I'm old-school emacs / command-line
473 2013-01-29 15:15:06 <denisx> gavinandresen: sure, but then you get the newest clang version on osx
474 2013-01-29 15:15:19 <gavinandresen> I get the newest clang and lldv from macports
475 2013-01-29 15:15:59 <denisx> ok
476 2013-01-29 15:19:46 <HM> Clangs error reporting is gorgeous
477 2013-01-29 15:20:02 <HM> I still prefer GCC for real compilation though
478 2013-01-29 15:20:32 <HM> whenever i hit a compile error in gcc i'll often just hit clang to decipher it for me
479 2013-01-29 15:23:36 <jgarzik> Luke-Jr: hehehe
480 2013-01-29 15:24:00 <ThomasV> gavinandresen: I have a question about your p2sh example, https://gist.github.com/3966071
481 2013-01-29 15:24:29 <ThomasV> I am trying to verify the signatures of that tx, manually
482 2013-01-29 15:25:04 <ThomasV> I assume that the string that is being signed is this one:
483 2013-01-29 15:25:07 <ThomasV> 0100000001aca7f3b45654c230e0886a57fb988c3044ef5e8f7f39726d305c61d5e818903c0000000017a914f815b036d9bbbce5e9f2a00abd1bf3dc91e9551087ffffffff0140420f00000000001976a914ae56b4db13554d321c402db3961187aed1bbed5b88ac0000000001000000
484 2013-01-29 15:25:12 <ThomasV> is that correct?
485 2013-01-29 15:25:20 <ThomasV> or did I forget something?
486 2013-01-29 15:26:33 <gavinandresen> the scriptSig in your vin is wrong
487 2013-01-29 15:26:47 <ThomasV> ok, what's wrong?
488 2013-01-29 15:27:38 <gmaxwell> sipa: I wonder how expensive it would be to verify block and undo data whenever doing a getblock on an older block.
489 2013-01-29 15:27:40 <gavinandresen> For a P2SH, instead of taking the HASH <> EQUAL from the previous output, you take the script FOR that hash (DUP HASH160 or CHECK_MULTISIG or whatever)
490 2013-01-29 15:28:17 <gmaxwell> sipa: validation doesn't care if old blocks are corrupted... and if most of the cost is IO doing it at a getblock time would make sense.
491 2013-01-29 15:28:17 <ThomasV> ooooh
492 2013-01-29 15:30:04 <ThomasV> gavinandresen: I take the script that is being pushed in the final transaction?
493 2013-01-29 15:30:09 <gavinandresen> ThomasV: yes
494 2013-01-29 15:30:22 <ThomasV> so, starting with op_2 in that example?
495 2013-01-29 15:30:28 <sipa> gmaxwell: block hash is verified anytime it's read from disk
496 2013-01-29 15:30:35 <jgarzik> ACTION looks forward to Feb 15th, when the coding may resume, and little kid time consumption is lessened
497 2013-01-29 15:32:06 <gavinandresen> ThomasV: yes, OP_2 <pk1> <pk2> <pk3> OP_3 OP_CHECKMULTISIG is what you'd put in the scriptSig to compute the tx hash to sign.
498 2013-01-29 15:32:37 <ThomasV> gavinandresen: ok, great. I spent 2 days thinking it was what I put above :(
499 2013-01-29 15:32:55 <gavinandresen> ThomasV: sorry!
500 2013-01-29 15:35:52 <gavinandresen> ThomasV: I should have given a walkthrough example of exactly what was signed in BIP 16
501 2013-01-29 15:36:48 <ThomasV> well, I always try to reverse engineer existing transactinos, instead of readin the code. I guess that's not the case of most people
502 2013-01-29 15:37:01 <sipa> ThomasV: i think it is :)
503 2013-01-29 15:37:11 <ThomasV> heh
504 2013-01-29 15:37:24 <gavinandresen> ThomasV: the BIP wording is kind of subtle, but correct: "{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey."
505 2013-01-29 15:41:56 <ThomasV> gavinandresen: thanks a lot, it works now :)
506 2013-01-29 15:42:07 <ThomasV> I should have asked you earlier :)
507 2013-01-29 15:42:13 <ThomasV> bye
508 2013-01-29 15:45:50 <BCB> ;;ticker
509 2013-01-29 15:45:50 <gribble> BTCUSD ticker | Best bid: 19.40037, Best ask: 19.49997, Bid-ask spread: 0.09960, Last trade: 19.39936, 24 hour volume: 99759.90989864, 24 hour low: 18.11001, 24 hour high: 19.80000, 24 hour vwap: 18.95994
510 2013-01-29 15:45:54 <BCB> oh yea
511 2013-01-29 15:46:01 <BCB> ;;seen DBordello
512 2013-01-29 15:46:01 <gribble> DBordello was last seen in #bitcoin-dev 8 weeks, 4 days, 16 hours, 21 minutes, and 37 seconds ago: <DBordello> It looks like blk0002.dat is almost full
513 2013-01-29 15:46:41 <BCB> who do you do later tell
514 2013-01-29 15:46:47 <BCB> /later tell
515 2013-01-29 15:46:49 <BCB> ??
516 2013-01-29 15:47:08 <BCB> ;;seeen ATC777
517 2013-01-29 15:47:09 <gribble> Error: "seeen" is not a valid command.
518 2013-01-29 15:47:41 <jgarzik> <BitSynCom> let's hope Jeff receives his unit before batch #2 starts selling on EST 9:00 AM, January 31st, 2013.
519 2013-01-29 15:52:02 <pjorrit> maybe they should delay selling it until it actually arrives?
520 2013-01-29 16:16:10 <jgarzik> ACTION cannot resist responding: https://bitcointalk.org/index.php?topic=139733.0
521 2013-01-29 16:21:35 <HM> oO
522 2013-01-29 16:28:36 <BlueMatt> jgarzik: hey, whats wrong with teenagers with time on their hands?
523 2013-01-29 16:28:49 <BlueMatt> we wouldnt have UPnP support or wallet encryption without them ;)
524 2013-01-29 16:29:22 <sipa> and have a 0.8rc1 that violated the network rules :p
525 2013-01-29 16:29:38 <BlueMatt> what happened to 0.8rc1?
526 2013-01-29 16:30:10 <epscy> sipa: uh, what happened with rc1?
527 2013-01-29 16:32:12 <sipa> BlueMatt: we don't have one yet, but if you weren't there, we wouldn't have pulltester that detected 2 rule violations in ultraprune
528 2013-01-29 16:32:32 <sipa> and perhaps we would have moved for an rc1 already :)
529 2013-01-29 16:32:52 <BlueMatt> ohh, that
530 2013-01-29 16:32:55 <BlueMatt> yes
531 2013-01-29 16:33:30 <gavinandresen> three cheers for pull tester! which reminds me, some valgrind tests for pull tester need to be on my TODO list...
532 2013-01-29 17:03:40 <kuzetsa> jgarzik: I responded to that one too... because yes --> https://bitcointalk.org/index.php?topic=139733.msg1488383#msg1488383
533 2013-01-29 17:10:47 <HM> UPnP is kinda sucky from a security perspective
534 2013-01-29 17:18:28 <sipa> HM: it's a necessary evil hack to fix an otherwise unnecessary evil hack called NAT
535 2013-01-29 17:24:58 <Luke-Jr> HM: only if you erroneously perceive NAT as a security measure
536 2013-01-29 17:25:49 <kjj> hey Luke, if bfgminer marks a pool as dead, will it ever recover?
537 2013-01-29 17:27:16 <Luke-Jr> kjj: it could; in practice, I've not tested it lately
538 2013-01-29 17:27:31 <Luke-Jr> kjj: in theory, it should give it another chance every so often
539 2013-01-29 17:28:45 <kjj> happen to know off the top of your head how often that chance is?
540 2013-01-29 17:29:22 <Luke-Jr> no, but I can check :p
541 2013-01-29 17:30:00 <kjj> ok. I'll let it run then. let me know how long
542 2013-01-29 17:30:05 <Luke-Jr> looks like every 30 seconds to a minute
543 2013-01-29 17:30:49 <kjj> it has been back up for at least 15 minutes, probably closer to an hour, and it is still marked Status=Dead in pools|
544 2013-01-29 17:32:25 <kjj> hmm. I'm going to go plug a monitor in, see if there are any messages showing
545 2013-01-29 17:34:45 <kjj> nothing useful visible. it is in failover mode, with failover only enabled. does that change things?
546 2013-01-29 17:34:46 <Luke-Jr> kjj: maybe it really is dead? :p
547 2013-01-29 17:35:15 <kjj> no, it isn't dead. I fired up a second instance and that connected just fine. it is only the one that started while it was dead that won't retry
548 2013-01-29 17:36:31 <kjj> I have three boxes running p2pool. each one has a list of 5 pools, starting with localhost, and then the IPs of the three boxes, and then a backup pool (btcguild).
549 2013-01-29 17:37:06 <kjj> when the box starts, bfgminer starts early and fails down the list until it finds a running node, or hits the backup pool. but I want it to switch back to localhost when the local bitcoind catches up and p2pool starts
550 2013-01-29 17:39:11 <Luke-Jr> kjj: might be useful to make a debug log
551 2013-01-29 17:40:26 <kjj> well, that might be tricky... the system boots from PXE, so I'd have to build a new image to get logging from a cold start
552 2013-01-29 17:40:53 <kjj> might be able to fake by deleting the block chain and restarting everything. sec
553 2013-01-29 17:41:55 <Luke-Jr> hm
554 2013-01-29 17:42:02 <kjj> ooh. typo in your API-README. grep for "defails"
555 2013-01-29 17:46:05 <kjj> Unknown stratum msg "method not found" ?
556 2013-01-29 17:48:54 <Luke-Jr> kjj: probably unrelated
557 2013-01-29 17:49:07 <kjj> yeah, that's what I figured. it was connecting anyway
558 2013-01-29 17:49:39 <kjj> anyhow, I've started bfgminer and it failed down to #3 on the list, and I'm restarting bitcoind and p2pool. it'll take a long while for them to sync back up
559 2013-01-29 17:52:05 <kjj> I see messages going by now and then that it is testing 127.0.0.1, as it should
560 2013-01-29 17:56:36 <kjj> so far, looks like it is trying every 60 seconds on the dot
561 2013-01-29 18:04:22 <sipa> ;;genrate 685
562 2013-01-29 18:04:23 <gribble> The expected generation output, at 685.0 Mhps, given difficulty of 2968775.33208, is 0.116038071333 BTC per day and 0.00483491963888 BTC per hour.
563 2013-01-29 18:08:51 <HM> eeeesh
564 2013-01-29 18:09:14 <kjj> bitcoind still >100 blocks behind, but p2pool kicked in. bfgminer switched to it
565 2013-01-29 18:15:15 <kjj> looks like this time the recovery worked exactly as planned.
566 2013-01-29 18:15:47 <kjj> I'll update my PXE image to always log, and we'll see if it happens again after the next reboot
567 2013-01-29 18:16:57 <D34TH> coolio
568 2013-01-29 18:18:06 <kjj> hey Luke, can you put in a pidfile option?
569 2013-01-29 18:18:43 <Luke-Jr> kjj: patches welcome? :P
570 2013-01-29 18:18:50 <kjj> heh
571 2013-01-29 18:19:06 <Luke-Jr> kjj: but I'd like to get a working init setup at least for Openwrt, which might need that
572 2013-01-29 18:19:45 <kjj> I'd offer you half of the donations I've received for p2pcoin as a bounty, but I think you can guess what your cut would be
573 2013-01-29 18:20:24 <D34TH> half of nothing is nothing?
574 2013-01-29 18:22:02 <Luke-Jr> kjj: open a github issue and I'll hopefully get to it ;)
575 2013-01-29 18:23:57 <kjj> done
576 2013-01-29 18:53:49 <comboy> anybody knows order of magnitude of number of transactions up to now?
577 2013-01-29 18:56:23 <kjj> yes
578 2013-01-29 18:56:52 <comboy> thanks!
579 2013-01-29 18:57:17 <kjj> http://blockchain.info/charts/n-transactions-total
580 2013-01-29 18:57:51 <comboy> oh, I thought you were just playing with me, thanks a lot :)
581 2013-01-29 18:58:59 <comboy> wow, that's qust 11M? and 5M of that (judging from number of bets) is satoshidice? heh
582 2013-01-29 19:16:26 <sipa> comboy: 11897094 (from my debug.log file)
583 2013-01-29 19:16:31 <sipa> but you already know that i guess
584 2013-01-29 19:22:12 <comboy> yeah, about what blockchain.info says, thanks
585 2013-01-29 19:38:00 <Diapolo> sipa: are there known problems, when shuting down, while reindexing?
586 2013-01-29 19:38:18 <gmaxwell> There shouldn't be.
587 2013-01-29 19:41:35 <Diapolo> gmaxwell: I sometimes get an APPCRASH while aborting, dunno what causes this, perhaps some of my faulty code then :-D
588 2013-01-29 19:45:03 <sipa> Diapolo: no known problems with that
589 2013-01-29 19:45:08 <sipa> (at least to me)
590 2013-01-29 19:46:36 <Diapolo> sipa: did you try Bitcoin-Qt and shutdown while reindexing? just want to be sure
591 2013-01-29 19:48:14 <gmaxwell> Diapolo: I personally never tested reindex abort with -QT. I wouldn't be shocked if there was an issue.
592 2013-01-29 19:49:33 <Diapolo> I know Gavin want's to take a look at shutdown after 0.8, I guess there is plenty of room for optimisation there.
593 2013-01-29 19:50:20 <gmaxwell> optimization yea, but crashing is bad.
594 2013-01-29 19:51:13 <Diapolo> I don't want to say there IS a bug, as it could be caused by own stuff in the code, but I would love if one of you could give it a short try with current master code.
595 2013-01-29 19:53:16 <porquilho> gmaxwell
596 2013-01-29 19:53:21 <porquilho> don't play cards with satan
597 2013-01-29 19:53:25 <porquilho> he will deal you a awful hand
598 2013-01-29 19:54:34 <Diapolo> LOL ^^
599 2013-01-29 19:54:53 <porquilho> at least the satan is not here
600 2013-01-29 19:55:39 <porquilho> satan for everyone who doest know is TallTim
601 2013-01-29 19:55:46 <porquilho> i must get away from him
602 2013-01-29 19:56:01 <porquilho> for his blackness and blood will stain
603 2013-01-29 19:56:08 <porquilho> the pureness that i see
604 2013-01-29 20:17:26 <jrmithdobbs> do any cpus offer >64bit rotl/rotr ops yet?
605 2013-01-29 20:25:44 <Herodes> I've been looking at the bitcoin API, but I have a little trouble finding out what is the best way to list all transactions belonging to a certain address. Let's say I have bitcoin address X, then 4 different transactions are sent to this address within the last 5 minutes. What I want to extract is all incoming transactions to address X. Looking at the API, I couldn't find some direct command to do this.
606 2013-01-29 20:26:06 <Herodes> It seems like there's some solutions using the existing API, but it would require some fiddling and is not straightforward.
607 2013-01-29 20:26:08 <Herodes> Any ideas?
608 2013-01-29 20:27:25 <kjj> listunspent 1 999999 '["address1"]'
609 2013-01-29 20:28:08 <kjj> er, 0 and 1 might be a better fit for your timeline
610 2013-01-29 20:30:20 <Herodes> thanks, I'm looking into it.
611 2013-01-29 20:31:56 <Herodes> Hah, yes that worked beautifully for my purposes. Thanks a lot kjj. Very helpful.
612 2013-01-29 20:33:50 <porquilho> gmaxwell you probably will never see honesty
613 2013-01-29 20:33:57 <porquilho> if you keep banning people
614 2013-01-29 20:34:02 <porquilho> who are honest
615 2013-01-29 20:34:34 <porquilho> sometimes honesty and autheticity are not compactible with satan
616 2013-01-29 20:35:14 <porquilho> http://www.worriedshoes.com/g4/images/heremembered345.jpg
617 2013-01-29 20:35:37 <kjj> maybe we need a bot that can just autoban people on command, rather than making him go through all the hassle of opping up, banning, and dropping ops every time that tool gets a new proxy.
618 2013-01-29 20:35:39 <porquilho> and it never is
619 2013-01-29 20:36:04 <porquilho> yeah
620 2013-01-29 20:38:04 <Herodes> Ok, another question. when using gettransaction, there are two fields, time and timereceived. The time fields, can they be trusted to be up to date if the system clock is correct ? I assume these fields, at least time received is set when the node gets notified about the transaction ? Could the sender somehow manipulate these values ?
621 2013-01-29 20:38:58 <kjj> for a confirmed transaction, that will be the block timestamp, which should be sorta close-ish to when the block actually happened
622 2013-01-29 20:39:34 <kjj> oh, wait. you are talking about mempool stuff
623 2013-01-29 20:40:01 <Herodes> No, I'm just fiddling with php and bitcoind and trying to learn a bit about it.
624 2013-01-29 20:40:25 <kjj> If I were you, I'd ignore anything and everything concerning time
625 2013-01-29 20:40:41 <Herodes> Right.
626 2013-01-29 20:40:54 <Herodes> I was just curious as to when and how that value was set.
627 2013-01-29 20:41:01 <Herodes> esp. for 0 confirmation transactions.
628 2013-01-29 20:41:10 <gmaxwell> porquilho: who the heck are you????? I know you're not stamit.
629 2013-01-29 20:41:10 <Luke-Jr> Herodes: "time" follows some fuzzy "smart" logic
630 2013-01-29 20:41:29 <porquilho> im porquilho
631 2013-01-29 20:41:38 <porquilho> dont you remember me ?
632 2013-01-29 20:41:45 <Luke-Jr> Herodes: if you first see a transaction broadcast, it is usually the receive time
633 2013-01-29 20:41:46 <porquilho> i was excited about bitcoin until satan show up
634 2013-01-29 20:41:53 <jgarzik> Avalon batch email: https://bitcointalk.org/index.php?topic=137534.msg1488869#msg1488869
635 2013-01-29 20:41:53 <Luke-Jr> Herodes: if you first see it in a block, then it's usually the block time
636 2013-01-29 20:42:11 <Luke-Jr> Herodes: but it should almost never be a time before the transaction received prior to it
637 2013-01-29 20:42:24 <porquilho> i think you do remember me :<
638 2013-01-29 20:42:29 <porquilho> but you just dont want to
639 2013-01-29 20:42:40 <Herodes> How is a 0 confirmation transaction pushed to a node ? Is it pushed to all nodes at once, or is the network able to only send the notification to the node containing the receiving address ? What I mean is that once you send some coins, they show up instantly at the receiving end as 0/unconfirmed. How is that done ?
640 2013-01-29 20:42:49 <kjj> for unconfirmed transactions, those will be from your node. there are no timestamps for non-block transactions in the network protocol
641 2013-01-29 20:43:05 <Herodes> Luke-Jr: Ok, thanks.
642 2013-01-29 20:43:44 <Luke-Jr> Herodes: "instantly" can be minutes fwiw
643 2013-01-29 20:43:51 <Herodes> kjj: Like I thought. Thanks for confirming.
644 2013-01-29 20:43:58 <Luke-Jr> or never until confirmed, depending on the circumstances
645 2013-01-29 20:44:23 <kjj> but bitcoin timekeeping is funny. don't count on it being particularly accurate or meaningful
646 2013-01-29 20:45:06 <Herodes> Luke-Jr: I understand. But many times the receiver can see it quite quickly. How does that happen ? I understand there's a network message. But is this message sent to all nodes, or is it sent to the node that controls the receiving address only ?
647 2013-01-29 20:45:20 <Herodes> kjj: Point taken, I will not rely on timestamps.
648 2013-01-29 20:45:29 <Luke-Jr> Herodes: it's flooded to all nodes
649 2013-01-29 20:45:44 <Herodes> Ah ok.
650 2013-01-29 20:45:52 <Herodes> Thanks guys. Most helpful. Appreciated.
651 2013-01-29 20:46:37 <kjj> no one knows which node, if any, "owns" an address
652 2013-01-29 20:47:10 <Herodes> I read that you could trace the ip if a user runs the standard client. It was a thread about it on the bitcointalk forum.
653 2013-01-29 20:47:23 <Herodes> ie. trace the ip, given the bitcoin address.
654 2013-01-29 20:47:26 <kjj> you can calculate an address by hand and send coins to it, even though no node has ever known the keys to it
655 2013-01-29 20:47:48 <Herodes> yes. I am aware that you can use air gapped wallets.