1 2011-12-01 00:07:51 <graingert> sipa: can I see yonder thesis?
  2 2011-12-01 00:28:17 <CIA-100> bitcoin: Gavin Andresen master * r0305f60 / (2 files):
  3 2011-12-01 00:30:57 <CIA-100> bitcoin: Gavin Andresen master * ra7120a3 / (9 files in 2 dirs):
  4 2011-12-01 00:33:20 <luke-jr> gavinandresen: interesting how an actual consensus turns into "no consensus" at your single whim, with nobody given a chance to respond.
  5 2011-12-01 00:34:09 <gavinandresen> luke-jr: https://bitcointalk.org/index.php?topic=46925
  6 2011-12-01 00:34:13 <luke-jr> gavinandresen: you're also forgetting to merge coinbaser, which has far more consensus and testing than getmemorypool ever did since before 0.5 was feature-frozen, not to mention a number of other pull requests I see ready to go
  7 2011-12-01 00:35:26 <luke-jr> gavinandresen: 50% support there. What are you expecting? 100%?
  8 2011-12-01 00:35:46 <luke-jr> I suppose for that particular patch it *might* adversely affect the 50% that don't want it, but USUALLY that's not the case.
  9 2011-12-01 00:37:53 <luke-jr> I'm not sure there's any case where you *really* want the current behaviour though.
 10 2011-12-01 00:38:08 <luke-jr> I suppose a "automatically just include a fee if it's under X" might be a good compromise.
 11 2011-12-01 00:39:21 <luke-jr> gavinandresen: if you expect 100%, then no feature should EVER be added.
 12 2011-12-01 00:39:22 <gavinandresen> luke-jr: I think the prepare- and then commit- transaction approach would be much better.  It would kill more birds with fewer stones.
 13 2011-12-01 00:39:28 <gavinandresen> Not that I have anything against birds.
 14 2011-12-01 00:40:02 <luke-jr> gavinandresen: that approach would best be done with a session-oriented protocol; ie, not JSON-RPC
 15 2011-12-01 00:40:03 <gavinandresen> I don't expect 100%, I expect rough consensus.  50% ain't that.
 16 2011-12-01 00:40:22 <luke-jr> otherwise, you'll end up with locked coins that never get released
 17 2011-12-01 00:40:23 <gavinandresen> mmm.  JSON-RPC is what we got.
 18 2011-12-01 00:40:29 <luke-jr> 50% should be good enough for most cases.
 19 2011-12-01 00:40:39 <gavinandresen> And it would be "prepare and lock for N time"
 20 2011-12-01 00:47:15 <luke-jr> gavinandresen: coinbaser definitely has a rough consensus, and no adverse behaviour for people who don't use it
 21 2011-12-01 00:48:30 <doublec> wouldn't prepare and lock for N time be vulnerable to malicious users locking a sites wallet? By cancelling out at the "do you want to pay X" stage repeatedly?
 22 2011-12-01 00:48:51 <doublec> I like luke-jr's approach - it's one I proposed and is used in solidcoin iirc
 23 2011-12-01 00:49:52 <luke-jr> doublec: otoh, the lock/commit approach can emulate mine if there's a "cancel" method too
 24 2011-12-01 00:50:17 <luke-jr> but lock/commit/cancel requires much more invasive low-level changes
 25 2011-12-01 00:50:40 <doublec> luke-jr: true, as long as the programmer doesn't make an error. Explicit lock/unlock is prone to mistakes.
 26 2011-12-01 00:52:08 <luke-jr> in either case, Gavin's request for a backward compatible "just accept any fee" is reasonable
 27 2011-12-01 00:52:25 <luke-jr> unfortunately, I need to make a NEW pull request for that since he closed the existing one
 28 2011-12-01 00:52:28 <luke-jr> can't just append it
 29 2011-12-01 00:54:18 <gavinandresen> fine, I re-opened it.
 30 2011-12-01 01:40:47 <nn> so, is it still true that bitcoin doesn't use DNS in proxy mode? (reg. tor error msg.)
 31 2011-12-01 01:43:11 <luke-jr> nn: still? until very recently, the main bitcoin clients didn't use DNS at all
 32 2011-12-01 01:54:07 <cjdelisle> hahaha bitcoin gives up your ipee
 33 2011-12-01 01:54:42 <cjdelisle> that's pretty funny since it spams verisign's logs with every node's addr even if they try to use tor
 34 2011-12-01 01:56:21 <gmaxwell> cjdelisle: hm? if you use the socks stuff it shouldn't do that.
 35 2011-12-01 01:56:29 <gmaxwell> Did you check or are you guessing?
 36 2011-12-01 02:00:32 <cjdelisle> wild guess
 37 2011-12-01 02:00:50 <cjdelisle> based on what nn said
 38 2011-12-01 02:02:20 <nn> I was quoting Santoshi apparently, https://bitcointalk.org/index.php?PHPSESSID=8e13bb91e22a18c715c984cf6759025a&topic=26651.msg334716#msg334716
 39 2011-12-01 02:12:12 <gmaxwell> it's not that it "doesn't use DNS in proxy mode" its that it normally makes requests to IPs rather than names, because the p2p protocol (and IRC) communicate IP addresses to the nodes.
 40 2011-12-01 02:12:38 <gmaxwell> Tor's triggers a warning when apps connect to IPs rather than names because it's usually a sign of DNS leaks.
 41 2011-12-01 02:12:58 <gmaxwell> All that said, it might be prudent to validate that the 'new' DNSeed stuff didn't create an actual DNS leak.
 42 2011-12-01 02:13:01 <luke-jr> technically it "is": it's not using Tor for DNS
 43 2011-12-01 02:13:10 <luke-jr> Bitcoin is using its own p2p protocol for its "DNS"
 44 2011-12-01 02:13:26 <luke-jr> gmaxwell: I'm sure it did.
 45 2011-12-01 02:13:37 <luke-jr> gmaxwell: there's no way to do DNS lookups over SOCKS
 46 2011-12-01 02:13:50 <luke-jr> if you upgraded to SOCKS 5 you could *connect by DNS name*
 47 2011-12-01 02:13:54 <luke-jr> but no way to get the IP back
 48 2011-12-01 02:14:20 <gmaxwell> Right but do we use dnsseed mode when the proxy is enabled?
 49 2011-12-01 02:14:39 <luke-jr> why not?
 50 2011-12-01 02:15:13 <gmaxwell> ha. Because of the DNS leak there.
 51 2011-12-01 02:17:46 <nn> you guys are out of control, bitcoin aint anonymous for shit. you mean you haven't checked for DNS leaks?
 52 2011-12-01 02:18:09 <nn> NOW you're telling me?
 53 2011-12-01 02:19:18 <luke-jr> nn: Bitcoin isn't supposed to be anonymous, idiot
 54 2011-12-01 02:19:20 <gmaxwell> nn: Tone down the attitude.
 55 2011-12-01 02:20:24 <gmaxwell> Moreover, the only thing that dnsseed could leak is that you've started bitcoin not anything about what you're doing with it.
 56 2011-12-01 02:20:37 <gmaxwell> And yes, people have checked, but its a new feature.
 57 2011-12-01 02:21:31 <gmaxwell> If you're actually in a situation where dns leaks would matter then you're a fool if you haven't made them impossible by blocking them locally.
 58 2011-12-01 02:21:57 <gmaxwell> Tons of applications have them... and they're closed completely in proper distributions for anonymity like tails.
 59 2011-12-01 02:22:05 <nn> I'm just saying, you might be putting innocent people in harms way by the current illusion of bitcoins being anonymous with tor.
 60 2011-12-01 02:22:57 <gmaxwell> As I mentioned, the only thing it would potentially leak is that you started bitcoin.
 61 2011-12-01 02:23:07 <nn> And your IP?
 62 2011-12-01 02:23:15 <gmaxwell> What about your IP?
 63 2011-12-01 02:23:41 <nn> Having bitcoin do a DNS lookup, not through tor, would reveal your true IP?
 64 2011-12-01 02:23:48 <gmaxwell> It would leak that someone at your IP started bitcoin, thats it.
 65 2011-12-01 02:24:06 <gmaxwell> (e.g. like downloading bitcoin software not via tor)
 66 2011-12-01 02:24:45 <nn> That's already a lot, if you ask me.
 67 2011-12-01 02:25:49 <nn> However, bitcoin _should_ be anonymous though, philosophically speaking? Isn't that part of the beauty of it? Cause if it's not "free," then who's controlling it...
 68 2011-12-01 02:26:07 <gmaxwell> It sounds like your conflating things there.
 69 2011-12-01 02:26:29 <gmaxwell> What does being anonymous have to do with someone controlling it?
 70 2011-12-01 02:27:08 <nn> Ask anyone who's been put on a non-desirable list (eg. Wikileaks, Hamas), and what happened to their funds.
 71 2011-12-01 02:27:54 <nn> If it's not anonymous, it's not free; and if it's not free, some authority controls it.
 72 2011-12-01 02:27:59 <gmaxwell> Bitcoin doesn't make it possible to freeze people's funds even if you know who they are.
 73 2011-12-01 02:29:28 <gmaxwell> In any case, disclosing that you're running bitcoin probably does not pose any risk wrt that.
 74 2011-12-01 02:29:34 <nn> Knowing who you are as you fund Wikileaks is a problem. I mean, that's obvious. Funders to Wikileaks have been harassed. Funders to democratically elected governments (eg. Hamas) have been charged for funding terrorism and whatnot.
 75 2011-12-01 02:29:36 <luke-jr> nn: no, Bitcoin is not anonymous.
 76 2011-12-01 02:30:02 <gmaxwell> And, as luke pointed out, it sounds like its not possible to make dnsseed work over tor.
 77 2011-12-01 02:30:19 <luke-jr> nn: so don't fund questionable things
 78 2011-12-01 02:30:19 <nn> Anywho, you guys are doing a great job - I suppose you're devs.
 79 2011-12-01 02:30:36 <luke-jr> nn: most of us only want Bitcoin to be used for "clean" purposes
 80 2011-12-01 02:31:05 <gmaxwell> Bitcoin uses weak anonymity to provide conventional privacy. If for some reason you need actual anonymity thats very hard and no software alone can provide that.
 81 2011-12-01 02:31:13 <nn> luke-jr: but that's the point, who says what's "questionable"? You? Me? the US?
 82 2011-12-01 02:31:28 <luke-jr> nn: whoever you're worried about
 83 2011-12-01 02:31:46 <luke-jr> nn: if you stand firm behind your money transfers, you have nothing to fear :P
 84 2011-12-01 02:32:02 <luke-jr> if you're doing something illegal, you SHOULD be prosecuted
 85 2011-12-01 02:32:08 <luke-jr> take responsibiltiy!
 86 2011-12-01 02:32:23 <nn> luke-jr: I agree.
 87 2011-12-01 02:32:52 <gmaxwell> luke-jr: What if you want to send tithings to the catholic church from Saudi Arabia
 88 2011-12-01 02:32:56 <gmaxwell> ? :)
 89 2011-12-01 02:33:13 <nn> gmaxwell: also ;)
 90 2011-12-01 02:33:25 <luke-jr> gmaxwell: ok you win
 91 2011-12-01 02:34:32 <gmaxwell> But yes, bitcoin isn't an anonymity system. It's only anonymous enough to compensate for the fact that the transaction data is all public.
 92 2011-12-01 02:34:55 <nn> I suppose.
 93 2011-12-01 02:35:39 <gmaxwell> So in any case, I think we should probably disable dnsseed if a proxy is in use.. if someone is using a proxy then they may likely want to conceal that they are running bitcoin at all.
 94 2011-12-01 02:35:54 <gmaxwell> but given that.... we're down a useful seeding method...
 95 2011-12-01 02:36:03 <luke-jr> gmaxwell: IMO, just change the default
 96 2011-12-01 02:36:20 <luke-jr> ie, let them explicitly enable it with -dnsseed
 97 2011-12-01 02:36:24 <gmaxwell> What, dnsseed off by default iff you use proxy? That makes sense to me. Yep.
 98 2011-12-01 02:36:26 <nn> what's a DCC CHAT?
 99 2011-12-01 02:36:55 <gmaxwell> A way of getting someone's IP when they're using IRC over tor. ;)
100 2011-12-01 02:37:02 <luke-jr> nn: someone attempting to crash your IRC client probably
101 2011-12-01 02:37:06 <gmaxwell> ... it's an IRC chat that goes direct client to client.
102 2011-12-01 02:37:14 <luke-jr> gmaxwell: I've never seen it used legitly :P
103 2011-12-01 02:37:34 <nn> well, -jcald- just DCC'd me.
104 2011-12-01 02:37:57 <gmaxwell> in the past when I've known of irc ops who snooped I used it.. these days I just use crypto. hurray for crypto.
105 2011-12-01 02:38:28 <gmaxwell> I don't know who that is.
106 2011-12-01 02:38:38 <nn> Don't they have better things to do...
107 2011-12-01 02:38:42 <gmaxwell> I don't think they're in this channel.
108 2011-12-01 02:38:51 <nn> No, he's not.
109 2011-12-01 02:39:07 <Diablo-D3> dongs.
110 2011-12-01 02:39:38 <nn> Is that all it takes? Make a philosophical argument on wikileaks, and they try to pin you?
111 2011-12-01 02:39:46 <gmaxwell> nah.
112 2011-12-01 02:40:04 <gmaxwell> Though going on about anonymity sometimes makes people want to prove a point.
113 2011-12-01 02:40:11 <nn> Then who is this op?
114 2011-12-01 02:40:22 <gmaxwell> op?
115 2011-12-01 02:40:38 <nn> gmaxwell: if he's not in the channel?
116 2011-12-01 02:40:44 <gmaxwell> Are you in any others?
117 2011-12-01 02:40:48 <gmaxwell> It could have just been a typo.
118 2011-12-01 02:42:34 <nn> He's not in any of my channels.
119 2011-12-01 02:43:51 <jrmithdobbs> luke-jr: really? never been on an irc network with crappy nosey oppers?
120 2011-12-01 02:44:14 <nn> There are no coincidences... (twilight zone music). Anywho, could be just some douche trying to make a point, yeah.
121 2011-12-01 02:44:16 <jrmithdobbs> or needed to transfer legitimate backup copies of copyrighted material?
122 2011-12-01 02:45:01 <nn> So, it's a way to transfer files directly? Meaning, it could be a cute little trojan - and revealing my IP?
123 2011-12-01 02:45:06 <gmaxwell> nn: I've made points before... so I fully sympathize.
124 2011-12-01 02:45:33 <nn> I'm in an internet cafe with 60 other laptoppers, though so... ;P
125 2011-12-01 02:46:22 <luke-jr> jrmithdobbs: I only use FreeNode.
126 2011-12-01 02:46:32 <jrmithdobbs> freenode's not that old
127 2011-12-01 02:46:44 <nn> Any way to find this guy?
128 2011-12-01 02:46:47 <jrmithdobbs> but ya, dcc chat and file transfers used to actually be used for things
129 2011-12-01 02:46:53 <jrmithdobbs> not really so much any more
130 2011-12-01 02:47:16 <gmaxwell> I have no confidence that freenode is free of snoops.. but I don't happen to know if it directly so I can pretend its not happening.
131 2011-12-01 02:47:36 <jrmithdobbs> ya, I just don't care
132 2011-12-01 02:47:46 <jrmithdobbs> tbqh I'm not worried about the freenode staff since lilo kicked it
133 2011-12-01 02:47:50 <jrmithdobbs> and I don't care how awful that sounds
134 2011-12-01 02:48:37 <gmaxwell> ::shrugs:: I've said similar.
135 2011-12-01 02:49:05 <gmaxwell> The real sin is the IRC protocol it should make it impossible for IRC operators to snoop invisibly.
136 2011-12-01 02:50:19 <upb> heh, the whole architecture is not designed with this in mind
137 2011-12-01 02:50:38 <upb> if you have a server, you can introduce users in every channel and log all traffic of the whole network anyway
138 2011-12-01 02:52:19 <gmaxwell> upb: but it wouldn't be invisible.
139 2011-12-01 02:52:30 <gmaxwell> e.g. "Who is that bob guy? /kick"
140 2011-12-01 02:52:47 <upb> true
141 2011-12-01 02:53:19 <gmaxwell> of course, traffic analysis is almost as valuable as seeing the cleartext.. but you can only fix so much.
142 2011-12-01 02:53:29 <gmaxwell> making all IRC channels CBR would have quite high overhead. :)
143 2011-12-01 02:57:11 <cjdelisle> heh
144 2011-12-01 02:57:21 <cjdelisle> I had no problem wandering around
145 2011-12-01 02:57:43 <cjdelisle> when I figured out the right nick I got tons of incoming connections too
146 2011-12-01 02:58:03 <cjdelisle> had 1000 sockets before the isp threw in the towel
147 2011-12-01 02:58:21 <gmaxwell> cjdelisle: whats this?
148 2011-12-01 02:58:35 <cjdelisle> joining all of the channels in lfnet
149 2011-12-01 02:58:43 <cjdelisle> using my encoded ip/port as my nick
150 2011-12-01 02:58:48 <cjdelisle> (in irssi)
151 2011-12-01 02:58:49 <gmaxwell> you can only join 25.
152 2011-12-01 02:58:54 <gmaxwell> lfnet limits the joins.
153 2011-12-01 02:58:59 <cjdelisle> yeap
154 2011-12-01 02:59:02 <cjdelisle> so I cycled
155 2011-12-01 02:59:11 <gmaxwell> Yea, I have a patch to bitcoin that does this.
156 2011-12-01 02:59:28 <gmaxwell> the current scheme is likely to cause network partitioning.
157 2011-12-01 02:59:43 <cjdelisle> had 1000 connections at peak then the dsl modem lost the connection
158 2011-12-01 02:59:47 <gmaxwell> esp since stable clients are mostly invisible to others.
159 2011-12-01 03:00:15 <cjdelisle> could have been overloaded nat tables but I'm surprised the whole connection would blow up
160 2011-12-01 03:00:35 <gmaxwell> I'm not.
161 2011-12-01 03:00:50 <gmaxwell> "session table full I think I'll just randomly overwrite my memory now.. weeee"
162 2011-12-01 03:00:57 <cjdelisle> hehehe
163 2011-12-01 03:01:03 <cjdelisle> wouldn't surprise me
164 2011-12-01 03:01:25 <cjdelisle> or I guess it would...
165 2011-12-01 03:01:40 <gmaxwell> what kind of router?
166 2011-12-01 03:01:44 <graingert> well it won't overwrite randomly
167 2011-12-01 03:01:56 <graingert> just off the end of the array
168 2011-12-01 03:01:58 <gmaxwell> I mean most soho boxes.. software testing consists of "light turns green after applying 12vdc"
169 2011-12-01 03:02:00 <cjdelisle> just a westell dshell thing
170 2011-12-01 03:02:24 <cjdelisle> openwrt
171 2011-12-01 03:02:26 <graingert> *currently rolling about in laughter at gmaxwell's comment*
172 2011-12-01 03:03:09 <cjdelisle> they're nice since you can fire up telnetd on them and monkey around
173 2011-12-01 03:03:40 <gmaxwell> I'll never forget the time when ... I'd just gotten I new intern in the office and I was telling him what crap this router we had was... and I was at the time dorking around with a tool to generate random packets.
174 2011-12-01 03:04:21 <gmaxwell> "I bet if I sent this a <types> ICMP REDIRECT FROM <types> itself <types> to <types> itself that it'll blow up. <enter>"
175 2011-12-01 03:04:33 <gmaxwell> then over the cube walls "greg did the network just go down?"
176 2011-12-01 03:04:38 <gmaxwell> oops.
177 2011-12-01 03:04:48 <cjdelisle> hehehe
178 2011-12-01 03:05:11 <gmaxwell> It was then hard to explain that I didn't actually expect that to happen even though I _said_ it would happen, it was just hyperbole...
179 2011-12-01 05:00:23 <FellowTraveler> hi all.
180 2011-12-01 14:21:37 <makomk> By the way, did the issue where you could spam Bitcoin nodes with orphan blocks and bloat their block file ever get fixed?
181 2011-12-01 14:25:51 <kinlo> I don't think you can fix that
182 2011-12-01 14:26:13 <kinlo> however, you need to mine those blocks, so you need a LOT of hashing power to execute the attack
183 2011-12-01 14:28:41 <makomk> The problem was/is that it's quite happy to accept really old orphans. As in, back in the difficulty-1 era.
184 2011-12-01 14:29:30 <UukGoblin> which might be needed in case someone ever produces a longer chain ;-]
185 2011-12-01 14:30:06 <UukGoblin> actually...
186 2011-12-01 14:30:08 <luke-jr> no
187 2011-12-01 14:30:12 <luke-jr> makomk has a point
188 2011-12-01 14:30:20 <luke-jr> orphans before the last checkpoint should be rejected
189 2011-12-01 14:31:07 <UukGoblin> if someone built a chain of 200 000 blocks all at difficulty 1, wouldn't it supersede the current one? :-P
190 2011-12-01 14:31:12 <UukGoblin> must be something wrong with my logic there
191 2011-12-01 14:31:27 <UukGoblin> or does bitcoin take difficulty into account when calculating "length"?
192 2011-12-01 14:31:32 <makomk> UukGoblin: it chooses the chain with the most work, not the most blocks.
193 2011-12-01 14:31:42 <UukGoblin> right
194 2011-12-01 14:31:49 <UukGoblin> good. ;-]
195 2011-12-01 14:32:14 <UukGoblin> I got worried there for a sec
196 2011-12-01 14:32:48 <luke-jr> UukGoblin: bitcoind-based clients also reject things changing blocks before they were released
197 2011-12-01 14:32:54 <luke-jr> UukGoblin: the hash is hard-coded into them
198 2011-12-01 14:32:57 <makomk> I'm mostly curious because someone's carrying out a superficially similar spamming attack against Solidcoin, and there might be copycats.
199 2011-12-01 14:33:25 <UukGoblin> luke-jr, you could still produce a longer chain that starts from the checkpoint
200 2011-12-01 14:33:37 <UukGoblin> or after the checkpoint
201 2011-12-01 14:34:00 <luke-jr> UukGoblin: not at diff 1
202 2011-12-01 14:34:36 <UukGoblin> well...
203 2011-12-01 14:35:14 <UukGoblin> he can produce a 2-weeks worth of, say, 5 blocks, which will drop the diff down and carry on from there
204 2011-12-01 14:35:24 <UukGoblin> actually
205 2011-12-01 14:35:29 <UukGoblin> that'd have to be a bit longer ;-]
206 2011-12-01 14:36:06 <UukGoblin> but cool, if bitcoin takes amount of work rather than chain length, there's no issue
207 2011-12-01 14:36:59 <gavinandresen> makomk: see https://github.com/bitcoin/bitcoin/pull/534
208 2011-12-01 14:37:29 <gavinandresen> Actually, maybe I should just pull that now....
209 2011-12-01 14:39:57 <luke-jr> gavinandresen: reckon that one is a bugfix (and thus for 0.4.x and 0.5.x)?
210 2011-12-01 14:40:15 <makomk> gavinandresen: ah, neat!
211 2011-12-01 14:40:28 <gavinandresen> sure, it fixes a potential denial-of-service attack
212 2011-12-01 14:41:04 <luke-jr> hmm, does it depend on the "anti-DoS" code?
213 2011-12-01 14:41:11 <luke-jr> I hadn't merged that
214 2011-12-01 14:46:09 <makomk> gavinandresen: what happens in the case where we do have the previous block, but it's (for example) block #2?
215 2011-12-01 14:46:25 <luke-jr> rtfs
216 2011-12-01 14:47:17 <makomk> Ah, that's not what it's targetting.
217 2011-12-01 14:48:33 <makomk> In practice it appears from the Solidcoin incident that spamming nodes with blocks that we do have the previous block for may still cause enough memory bloat to be disruptive, but that's quite a bit nastier.
218 2011-12-01 14:49:34 <gavinandresen> my pull makes that impossible, because orphan blocks are required to have a plausible amount of proof-of-work
219 2011-12-01 14:50:00 <gavinandresen> (don't tell the solidcoin guys, though, I don't want them stealing my code)
220 2011-12-01 14:50:37 <gavinandresen> (not that they would, anyway, because they know I'm a great big fat idiot)
221 2011-12-01 14:51:12 <makomk> It wouldn't help them anyway ;-). They're being attacked with blocks that are minimum-difficulty, valid, and recent due to a big fat security hole in the trust node stuff.
222 2011-12-01 14:51:26 <gavinandresen> speaking of which, what HAVE the solidcoin guys been up to recently?  have they done anything worth thinking about doing in bitcoin?
223 2011-12-01 14:52:03 <makomk> They have a
224 2011-12-01 14:52:38 <makomk> neat feature for displaying fees before you attempt a transaction, I think.
225 2011-12-01 14:52:40 <luke-jr> gavinandresen: unlikely.
226 2011-12-01 14:52:58 <luke-jr> makomk: wxBitcoin always had that
227 2011-12-01 14:53:05 <luke-jr> and Bitcoin-Qt does too I think
228 2011-12-01 14:53:55 <makomk> Also, unless I'm misreading this it only checks ComputeMinWork if it doesn't have the block corresponding to hashPrevBlock.
229 2011-12-01 14:56:04 <gavinandresen> makomk: good catch... let me think a bit....
230 2011-12-01 14:59:58 <gavinandresen> makomk: mapBlockIndex does not contain orphan blocks (mapOrphans does).  So !mapBlockIndex.count(pblock->hashPrevBlock)  will be true for all orphan blocks...
231 2011-12-01 15:02:11 <gavinandresen> makomk: if the block does build on the best tip-of-chain, then the proof-of-work checks in AcceptBlock will keep bogus blocks from bloating memory or disk.
232 2011-12-01 15:03:17 <makomk> What happens if it builds on an old but in-chain block?
233 2011-12-01 15:03:50 <gavinandresen> makomk: how old?
234 2011-12-01 15:04:05 <gavinandresen> ... if after the last checkpoint, then as long as it has plausible proof-of-work then it is OK.
235 2011-12-01 15:04:21 <makomk> Block 2, for example.
236 2011-12-01 15:04:49 <gavinandresen> During initial block download you mean?  Or after you have the whole chain?
237 2011-12-01 15:04:57 <makomk> After you have the whole chain.
238 2011-12-01 15:06:07 <gavinandresen> lemme think some more.... and maybe write another unit test....
239 2011-12-01 15:10:37 <gavinandresen> makomk: I think you might be right-- building on (say) block 2 with difficulty-1 blocks with current timestamps might work.  Another check, to reject blocks that build on blocks before the last checkpoint, might be needed.  I'll write a test.
240 2011-12-01 15:10:51 <devrandom> gavinandresen: I hear you will be visiting SF bay area, cool...
241 2011-12-01 15:11:04 <gavinandresen> devrandom: yes, next week.  You out there?
242 2011-12-01 15:11:25 <devrandom> yup
243 2011-12-01 15:11:52 <devrandom> in SF actually, but I visit the mountain view campus
244 2011-12-01 15:12:20 <gavinandresen> devrandom: cool.  I don't have plans for lunch on Wednesday, want to meet?
245 2011-12-01 15:12:40 <gavinandresen> (I'll be in the city)
246 2011-12-01 15:13:10 <devrandom> I would love to
247 2011-12-01 15:24:05 <TD> evening chaps
248 2011-12-01 15:26:22 <devrandom> TD: hey there... too bad you are not in town, looks like a bitcoin party
249 2011-12-01 15:29:28 <gavinandresen> TD: thanks for the OP_EVAL code review
250 2011-12-01 15:45:46 <UukGoblin> heh, bitcoincharts.com (at 27007) reports trades in future from bitstampUSD
251 2011-12-01 15:45:57 <UukGoblin> 164237 <+amphipod> Dec01 16:46:14 bitstamp    14.5208 @     3.46       USD
252 2011-12-01 15:46:10 <UukGoblin> the timestamp of this message is in HHMMSS format
253 2011-12-01 15:46:36 <nanotube> it's utc
254 2011-12-01 15:47:48 <UukGoblin> my timestamp is UTC too
255 2011-12-01 15:48:26 <UukGoblin> their clock is probably off, it's a ~4 minute difference
256 2011-12-01 16:17:52 <gavinandresen> TD: I just committed an updated/rebased OP_EVAL pull request, incorporating most of your code review suggestions.
257 2011-12-01 16:38:06 <nanotube> UukGoblin: ah yea probably.
258 2011-12-01 16:54:59 <TD> gavinandresen: great!
259 2011-12-01 16:55:04 <TD> hope it was helpful and not too nitpicky :)
260 2011-12-01 16:55:31 <TD> devrandom: yeah, enjoy it. wish i could be there. i think there may be another meetup in zurich either in early dec or next year now
261 2011-12-01 16:57:02 <dikidera> Can someone tell me more about this TX and how it's possible? http://blockexplorer.com/tx/fcd2f712070a895f6a92d5913a3341bcbc15e12a72c3ec44af246291c5ba1d3b#o3
262 2011-12-01 16:57:16 <dikidera> Afaik, sending 1 satoshi shouldn't be possible
263 2011-12-01 16:57:44 <TD> there's no limit on how small the payment can be, but you have to provide a fee in order to do it
264 2011-12-01 16:58:02 <TD> which makes it fairly pointless if you only use a small transaction. in this case the sender paid a fee of 0.02 btc to do that tx
265 2011-12-01 16:58:30 <TD> (well, unless you find a miner willing to include)
266 2011-12-01 16:58:34 <Eliel> dikidera: entirely possible for a tx like that to be in the blockchain. As I understand, though, no standard client would accept such a transaction though.
267 2011-12-01 16:58:57 <dikidera> so what...someone included that in his own block?
268 2011-12-01 16:58:58 <dikidera> As in he mined it himself to include the tx?
269 2011-12-01 16:59:00 <Eliel> as in, they would not propagate it nor include it in blocks they're mining.
270 2011-12-01 16:59:24 <Eliel> dikidera: or alternatively convinced some pool owner to help with it
271 2011-12-01 16:59:30 <dikidera> Why?
272 2011-12-01 16:59:38 <dikidera> Such a tx is pointless
273 2011-12-01 17:00:00 <Eliel> well, the amount of txfee paid might mean it's valid though.
274 2011-12-01 17:00:15 <Eliel> that tx has got 0.0245 in fees
275 2011-12-01 17:00:58 <Eliel> look at the addresses used. Almost all of them contain a word or acronym of some sort.
276 2011-12-01 17:02:17 <Eliel> basically, someone claiming loads of addresses for ... what was it called? firstbits?
277 2011-12-01 17:02:32 <dikidera> firstbits?can you elaborate?
278 2011-12-01 17:03:21 <Eliel> well, actually, not so sure of firstbits but something similar is my guess.
279 2011-12-01 17:03:32 <Eliel> wtf and lol seem to be rather common in those addresses
280 2011-12-01 17:04:32 <Eliel> firstbits (if I remember the name right) is a service that allows you to give it the first few characters of an address and it'll return the first address that was ever seen in the blockchain that starts with those characters
281 2011-12-01 17:06:40 <Turingi> is it still possible to post transactions to raw keys rather than addresses?
282 2011-12-01 17:06:48 <Turingi> re
283 2011-12-01 17:06:51 <Turingi> bitcoinFS
284 2011-12-01 17:07:18 <Eliel> Turingi: I would think it is.
285 2011-12-01 17:07:20 <TD> Turingi: yep
286 2011-12-01 17:08:44 <Eliel> dikidera: so, the most likely purpose of that mammoth of a transaction is to claim several short firstbits addresses. Speculatively that is. I guess the creator of those addresses expects to sell them for more than that transaction cost.
287 2011-12-01 17:12:33 <Turingi> is the bitcoin community apprehensive about a more largescale use of prepared transactions (like bitcoinFS)
288 2011-12-01 17:13:14 <Turingi> it would serve as an interesting globally available and unfalsifiable record set (if the records are old enough)
289 2011-12-01 17:13:31 <ThomasV> what is bitcoinfs?
290 2011-12-01 17:13:36 <TD> prepared transactions?
291 2011-12-01 17:13:53 <TD> if you mean stuffing random files into the block chain, yes the community is "apprehensive" about that
292 2011-12-01 17:14:02 <Turingi> ThomasV. TD: sending 0.01 BTC to a prepared address or to a prepared key
293 2011-12-01 17:14:17 <ThomasV> prepared?
294 2011-12-01 17:14:18 <TD> because it's abuse. make your own block chain and use merged mining to strengthen it
295 2011-12-01 17:14:18 <Turingi> ThomasV: the prepared address or key being some content you want to store
296 2011-12-01 17:14:51 <Turingi> ThomasV: the BTC is actually lost, in exchange for making a customized entry in the global block chain
297 2011-12-01 17:14:55 <TD> you're just hurting bitcoin by trying to abuse it as a filesystem. and you will produce a crappy filesystem too
298 2011-12-01 17:15:10 <Turingi> the bitcoin client could, however, be modified not to accept these customized addresses
299 2011-12-01 17:15:21 <ThomasV> great. what is the write latency of your filesystem?
300 2011-12-01 17:16:11 <Turingi> TD: not a crappy filesystem, but a global unfalsifiable registry
301 2011-12-01 17:16:17 <ThomasV> and how do you remove a file from that filesystem?
302 2011-12-01 17:16:19 <TD> registry of what?
303 2011-12-01 17:16:38 <TD> this topic has been discussed many times
304 2011-12-01 17:16:50 <Turingi> so you could post your ssh pubkeys if there's a protocol (RFC) for that
305 2011-12-01 17:16:52 <TD> see the forums. if you want to timestamp some content you can send a tx to a hash of that content
306 2011-12-01 17:17:03 <Turingi> you could use the blockchain to establish a network of trust
307 2011-12-01 17:17:06 <TD> but doing it on a large scale is a Bad Idea(tm)
308 2011-12-01 17:17:14 <TD> https://en.bitcoin.it/wiki/Alternative_Chains
309 2011-12-01 17:17:18 <TD> read that to see how you can do it in a better way
310 2011-12-01 17:17:37 <Turingi> yeah, but alternate blockchains don't have the bitcoin audience
311 2011-12-01 17:18:08 <TD> that's the whole point. why do you assume bitcoin users care about your filesystem? people who are interested in hosting random content of other people can install your software. merged mining can give you strength, assuming miners care.
312 2011-12-01 17:18:25 <Turingi> no entity is strong enough to subvert the global chain, at least not in an undetectable way
313 2011-12-01 17:18:37 <TD> that's absolutely not true
314 2011-12-01 17:18:48 <TD> anyone who can coerce the top 3 pools can beat the chain, currently. hopefully it'll change in future
315 2011-12-01 17:18:56 <TD> at any rate, merged mining gives you the ability to have that same strength
316 2011-12-01 17:19:11 <TD> IF you can convince people your idea is good and they should mine on both (it's free for them, they just have to install your software)
317 2011-12-01 17:19:13 <Turingi> can an attacker simply replace the blockchain entirely?
318 2011-12-01 17:19:24 <Turingi> with the current iteration of the client
319 2011-12-01 17:19:38 <Turingi> you could fix that problem by relying on the current chain as canonical
320 2011-12-01 17:19:53 <TD> no, but that's not the threat you face. you face the problem of people deleting or re-ordering content transactions (same as bitcoin itself)
321 2011-12-01 17:20:37 <ThomasV> TD: do you see reasons why large pools would be less influential in the future?
322 2011-12-01 17:21:00 <TD> i'm hoping eventually something like p2pool would be integrated by gavinandresen into the main client, and documentation would be updated to point people towards using the built-in support
323 2011-12-01 17:21:26 <gavinandresen> why do I have to do everything....
324 2011-12-01 17:21:30 <TD> :-)
325 2011-12-01 17:21:35 <TD> "pulled by"
326 2011-12-01 17:21:50 <TD> ThomasV: there'll always be large influential miners though.
327 2011-12-01 17:22:09 <Turingi> technically, someone could subvert bitcoin by subverting the servers that deliver the official client
328 2011-12-01 17:22:16 <Turingi> if they remain undetected
329 2011-12-01 17:22:19 <TD> subvert for new users yes
330 2011-12-01 17:22:29 <gavinandresen> jgarzik has been the "pull stuff relevant to mining" person on the team
331 2011-12-01 17:22:30 <TD> there is a reproducible build system to try and handle that
332 2011-12-01 17:22:54 <TD> unfortunately p2pool is a big python app. i guess it'd have to be rewritten in c++ at some point, once stable
333 2011-12-01 17:32:05 <jgarzik> gavinandresen: heh
334 2011-12-01 17:32:16 <jgarzik> gavinandresen: what issue/pull are people talking about today?
335 2011-12-01 17:32:37 <gavinandresen> jgarzik: luke-jr has been pushing the coinbaser pull.  TD was talking about p2pool...
336 2011-12-01 17:32:53 <TD> i'm talking about a non-existant pull
337 2011-12-01 17:33:08 <TD> reimplementing p2pool in c++ and merging with bitcoind would be a big pile of work
338 2011-12-01 17:33:17 <TD> and it'd need some kind of real website to direct miners there
339 2011-12-01 17:34:45 <jgarzik> yeah, I hadn't heard about any p2pool-related stuff other than the getmemorypool thing added in 0.5.0
340 2011-12-01 17:35:11 <jgarzik> coinbaser is a tough call...  I think it will get abused to add crap to the coinbase
341 2011-12-01 17:35:24 <jgarzik> but we do want to enable merged mining, conservely
342 2011-12-01 17:35:27 <jgarzik> conversely
343 2011-12-01 17:36:26 <jgarzik> though I suppose simply creating a block is a big hurdle, at this stage, so block spam isn't as large an issue as it might be theoretically than in practice
344 2011-12-01 17:38:43 <makomk> Someone could probably reuse most of the code from bitcoin when creating blocks; I think that's what the solidcoin spammer did.
345 2011-12-01 17:39:47 <gmaxwell> makomk: difficulty means computational difficulty.
346 2011-12-01 17:40:44 <gavinandresen> makomk: I'm testing a fix to the DoSorphans pull, by the way-- I'm pretty sure you're right, it didn't prevent a spammer from sending bogus chains built on very old blocks.
347 2011-12-01 17:40:45 <makomk> gmaxwell: ah, I see. Still doesn't sound like a huge hurdle; some of the block spam attacks work at difficulty one.
348 2011-12-01 17:41:17 <gmaxwell> makomk: we can forget those blocks, it's not at all the same problem.
349 2011-12-01 17:41:32 <gmaxwell> We should probably implement more countermeasures against that general class.
350 2011-12-01 17:41:51 <makomk> Sorry, doing too many things at once.
351 2011-12-01 17:41:55 <gmaxwell> So long as the attacker cant make problems in the longest chain the problem would be a temporary one.
352 2011-12-01 17:43:46 <luke-jr> jgarzik: the coinbase isn't unlimited.
353 2011-12-01 17:56:26 <denisx> damn, I can't start the mac bitcoin with -daemon anymore, it crashes with "Bus Error: 10"
354 2011-12-01 18:02:27 <gavinandresen> denisx: bitcoind ?  Works for me....
355 2011-12-01 18:03:22 <makomk> Mac OS X has an unreliable fork(), doesn't it?
356 2011-12-01 18:04:21 <denisx> gavinandresen: you start the Bitcoin-Qt with -daemon?
357 2011-12-01 18:04:51 <copumpkin> makomk: unreliable how?
358 2011-12-01 18:04:52 <gavinandresen> denisx: Oh, Bitcoin-Qt.  No I start that with "open Bitcoin-Qt.app"
359 2011-12-01 18:05:17 <denisx> gavinandresen: thats not with -daemon, thats the same like a doubleclick
360 2011-12-01 18:05:53 <gavinandresen> denisx: yup.  Why do you want to run the GUI -daemon?
361 2011-12-01 18:06:08 <makomk> copumpkin: tends to crash and burn if you're using GUI or desktop-related codde.
362 2011-12-01 18:06:10 <denisx> gavinandresen: I don't want the gui
363 2011-12-01 18:06:35 <gavinandresen> denisx: you're not compiling your own bitcoind for the Mac?
364 2011-12-01 18:06:37 <copumpkin> makomk: oh, that's Cocoa/Carbon that actively spit out a big error message saying don't do it
365 2011-12-01 18:06:44 <denisx> gavinandresen: no
366 2011-12-01 18:06:45 <copumpkin> makomk: the OS itself has no issue with it
367 2011-12-01 18:07:01 <denisx> gavinandresen: in earlier versions it was possible
368 2011-12-01 18:07:16 <makomk> IIRC the OS has an issue with any kind of forking with threads running or something, can't remember since I don't use it myself.
369 2011-12-01 18:08:38 <gavinandresen> denisx: I believe you.  It might be broken on all platforms, I'm not sure anybody ever tested GUI -daemon.  Distributing a binary Mac bitcoind is on the TODO list, but is low priority
370 2011-12-01 18:09:07 <copumpkin> makomk: I've never encountered such an issue, and it's a standard *nix implementation at all the low levels
371 2011-12-01 18:09:25 <copumpkin> makomk: but if you use the libraries apple endorses, they discourage you from forking
372 2011-12-01 18:09:50 <copumpkin> regarding threads, their compiler doesn't support thread-local variables in any easy way
373 2011-12-01 18:10:04 <copumpkin> but that's the only mac OS-specific thing I can think of regarding threads
374 2011-12-01 18:11:11 <gavinandresen> makomk: https://github.com/bitcoin/bitcoin/pull/534 updated.  I moved the checks to check all-blocks-not-building-directly-on-best-block
375 2011-12-01 18:11:22 <denisx> also on mac the daemon call is deprecated
376 2011-12-01 18:35:40 <denisx> jgarzik: is it intentional that you make two calls in pushpoold to valid_auth_hdr for every network?
377 2011-12-01 18:35:52 <denisx> or is it just a lazy way to get the username again? ;)
378 2011-12-01 18:37:14 <denisx> getwork
379 2011-12-01 18:37:22 <denisx> damn you autocorrect
380 2011-12-01 18:42:12 <forrestv> gavinandresen, if you need a tool to test generating orphan blocks, it could be done very easily by using some of p2pool's modules
381 2011-12-01 18:42:32 <forrestv> starting an rpc interface trying to generate blocks with a certain template would be a few lines
382 2011-12-01 18:42:53 <forrestv> (maybe more like 10)
383 2011-12-01 18:42:56 <gavinandresen> forrestv: thanks, I'll check it out.  Is p2pool on github?
384 2011-12-01 18:43:19 <forrestv> gavinandresen, yes. https://github.com/forrestv/p2pool
385 2011-12-01 18:45:56 <luke-jr> is p2pool free yet?
386 2011-12-01 18:46:03 <forrestv> luke-jr, yes.
387 2011-12-01 18:46:09 <luke-jr> what license?
388 2011-12-01 18:46:41 <luke-jr> I don't see one
389 2011-12-01 18:46:43 <luke-jr> -.-
390 2011-12-01 18:47:56 <forrestv> luke-jr, hm. any recommendations?
391 2011-12-01 18:48:12 <luke-jr> forrestv: BSD?
392 2011-12-01 18:48:23 <luke-jr> or MIT to match bitcoind maybe
393 2011-12-01 18:48:57 <denisx> I like BSD
394 2011-12-01 19:06:05 <gavinandresen> wumpus pulls GUI stuff
395 2011-12-01 19:06:31 <wumpus> I'm still a bit divided about signmessage
396 2011-12-01 19:06:41 <luke-jr> wumpus: wtf?
397 2011-12-01 19:06:56 <luke-jr> what's there to be divided about? >_<
398 2011-12-01 19:08:21 <helo> use case: you put a deposit address on a billboard (or in a newspaper advertisement), and anyone who can see it can deposit to the address
399 2011-12-01 19:08:46 <helo> you can't send the product back to them via the bitcoin network obviously, but later they can enter in a signed message into the delivery system to receive their product
400 2011-12-01 19:09:19 <luke-jr> that sure solves the "waiting for confirmations" problem too :o
401 2011-12-01 19:10:16 <wumpus> hmm
402 2011-12-01 19:11:13 <wumpus> so you could sign your address and send it?
403 2011-12-01 19:11:30 <luke-jr> that might be more complex though, since it'd ideally need to give the website the sig back directly
404 2011-12-01 19:11:39 <luke-jr> wumpus: well, you'd sign more than just your address IMO
405 2011-12-01 19:12:00 <luke-jr> I always include the current timestamp. Order details (product, etc) make sense too.
406 2011-12-01 19:12:33 <luke-jr> to automate stuff, the website really needs to provide the message to sign IMO
407 2011-12-01 19:12:39 <gavinandresen> helo:  I'm not sure I understand that use case.  You sign a message with one of the keys that you used to send to the address on the billboard?
408 2011-12-01 19:12:41 <wumpus> I keep thinking this makes more sense for a specific application than integrated into the client
409 2011-12-01 19:13:01 <luke-jr> wumpus: it makes sense for most every application
410 2011-12-01 19:13:11 <wumpus> it involves so much work at the side of the user if he has to insert all the information into the message himself
411 2011-12-01 19:13:13 <luke-jr> it proves you paid the bill, not someone else.
412 2011-12-01 19:13:28 <wumpus> right
413 2011-12-01 19:13:33 <luke-jr> that's why I was thinking a URI scheme extension might fit
414 2011-12-01 19:13:47 <luke-jr> even if the user needs to copy and paste the sig back out for now.
415 2011-12-01 19:13:52 <wumpus> ah I remember what I found wrong with it, it adds a tab, or doesn't it anymore?
416 2011-12-01 19:14:03 <luke-jr> wumpus: I took that out at your request
417 2011-12-01 19:14:20 <wumpus> great, so it's a menu option now?
418 2011-12-01 19:14:21 <helo> gavinandresen: yes
419 2011-12-01 19:14:24 <luke-jr> wumpus: now it's only accessible via the menu, or by selecing a Receiving Address on that page and clicking "Sign with"
420 2011-12-01 19:14:29 <wumpus> right
421 2011-12-01 19:14:34 <wumpus> much better
422 2011-12-01 19:14:38 <gavinandresen> helo: ... and how does the user know which addresses were used as inputs for that transaction?
423 2011-12-01 19:14:48 <helo> gavinandresen: good question :/
424 2011-12-01 19:15:14 <wumpus> hmm so it's really, really complicated to use
425 2011-12-01 19:15:19 <luke-jr> perhaps it should also be an option on transactions "Sign with this transaction's source key"
426 2011-12-01 19:15:31 <luke-jr> wumpus: not complicated for webapps
427 2011-12-01 19:15:37 <wumpus> maybe the signing should be integrated with the sending itself?
428 2011-12-01 19:15:41 <luke-jr> which can just tell the user what address they need to sign with
429 2011-12-01 19:15:48 <luke-jr> wumpus: maybe.
430 2011-12-01 19:16:11 <wumpus> but yeah otherwise it's kind of impossible to find out ...
431 2011-12-01 19:16:23 <wumpus> well not impossible but not withing the scope of a UI user :p
432 2011-12-01 19:16:28 <gavinandresen> "Sign with this address" feels like it too low-level for ordinary users--  "Prove I own this address" or "Prove I sent this transaction" sounds like a better level of abstraction
433 2011-12-01 19:16:35 <luke-jr> perhaps be able to add two different types to a send: destination/output, and message signature
434 2011-12-01 19:17:04 <Eliel> yes, it makes more sense as "Prove I sent this"
435 2011-12-01 19:17:20 <wumpus> yes that'd be better
436 2011-12-01 19:17:22 <Eliel> although, having to give it a message in that case might feel a bit strange for the user
437 2011-12-01 19:18:19 <luke-jr> "Confirm delivery confirmation details"
438 2011-12-01 19:18:25 <wumpus> well yeah you have to describe who you are in the message otherwise 'I' doesn't make much sense.. it only works to one side though, you could still lie that someone else sent it
439 2011-12-01 19:18:34 <helo> so if you send to an address with the "Prove I sent this", it might use some kind of standard identity string that you'd already have entered? name, address, email, phone (whichever checkboxes you fill in)
440 2011-12-01 19:18:39 <Eliel> or wait, it only proves the message you sign is from you... So yes, it is an intergral part, the message.
441 2011-12-01 19:19:18 <wumpus> yes it proves that the sender of the message owns the address/sent the transaction
442 2011-12-01 19:19:37 <wumpus> it does not prove who the sender is
443 2011-12-01 19:19:40 <luke-jr> probably the message needs to include the specific txid, at least.
444 2011-12-01 19:19:50 <luke-jr> since eWallets could reuse the same address for different people
445 2011-12-01 19:20:00 <wumpus> ok this explains why I kind of had trouble wrapping my head around it :-)
446 2011-12-01 19:20:20 <Eliel> it's kind of difficult to explain in one sentence :)
447 2011-12-01 19:20:21 <luke-jr> maybe a standard format is needed for messages too >_<
448 2011-12-01 19:20:23 <wumpus> hm more complications
449 2011-12-01 19:20:46 <wumpus> yes that was my point too, if you want to enforce a format to the message you really need to integrate this into some applications, not the generic client
450 2011-12-01 19:20:48 <luke-jr> YYYY-MM-DD@HH:MM:SS TXID: MESSAGE
451 2011-12-01 19:21:08 <Eliel> perhaps, send authenticated message attached to this transaction?
452 2011-12-01 19:21:12 <luke-jr> or I guess txid has a timestamp already
453 2011-12-01 19:21:14 <Eliel> as the action
454 2011-12-01 19:21:27 <Eliel> txid would then have to be a part of the message
455 2011-12-01 19:21:28 <wumpus> well then people will think it is sent with the transaction...
456 2011-12-01 19:21:48 <luke-jr> "Authorize transaction details" ?
457 2011-12-01 19:21:53 <wumpus> it's attached cryptographically but not in the normal sense
458 2011-12-01 19:22:19 <Eliel> wumpus: yes, would need auxiliary p2p network for the messages for it to make sense.
459 2011-12-01 19:22:22 <wumpus> without turning bitcoin into some kind of messenger/email client (which I'm very much against)
460 2011-12-01 19:22:32 <Eliel> that would automatically propagate the messages.
461 2011-12-01 19:22:53 <luke-jr> well, I'm assuming in any case the user gets the signature data as is already
462 2011-12-01 19:23:17 <Eliel> it would be quite handy though and could be implemented in a secure enough way that only participants in the transaction can read the messages too.
463 2011-12-01 19:23:33 <luke-jr> let people use something out-of-band to communicate the signature
464 2011-12-01 19:23:42 <luke-jr> like their normal email client, or a website
465 2011-12-01 19:23:49 <wumpus> right
466 2011-12-01 19:23:56 <wumpus> there's plenty of secure messaging systems already
467 2011-12-01 19:24:35 <Eliel> wumpus: it's the integration here that's crucial for usability. You can't achieve near the same level usability messaging through another system.
468 2011-12-01 19:24:47 <wumpus> a p2p messaging system is nice but not a thing bitcoin should strive to be
469 2011-12-01 19:24:55 <Eliel> then again, it doesn't have the official bitcoin client that has the feature.
470 2011-12-01 19:24:59 <wumpus> the key to secure software is limiting the scope
471 2011-12-01 19:25:02 <Eliel> *have to be
472 2011-12-01 19:25:49 <luke-jr> I like "Authorize transaction details"
473 2011-12-01 19:25:52 <wumpus> I don't really see that as an issue... you're already communicating some other way if you decide to send someone money
474 2011-12-01 19:26:01 <luke-jr> then just switch to the Sign Message not-a-tab with the correct address
475 2011-12-01 19:26:14 <luke-jr> maybe not perfect, but gets the job done for now
476 2011-12-01 19:26:25 <gmaxwell> wumpus: you want a very different network topology for p2p messaging.
477 2011-12-01 19:26:40 <wumpus> and then you want to prove that you were the person that sent a certain transaction
478 2011-12-01 19:26:56 <wumpus> gmaxwell: yes that's another problem
479 2011-12-01 19:27:39 <wumpus> luke-jr: yes something like that, though I'd really use a window instead of a not-a-tab
480 2011-12-01 19:27:56 <luke-jr> wumpus: nothing else uses a window&
481 2011-12-01 19:28:05 <wumpus> transaction details does
482 2011-12-01 19:28:07 <luke-jr> that's the beauty of Bitcoin-Qt
483 2011-12-01 19:28:10 <luke-jr> :/
484 2011-12-01 19:28:31 <helo> "save proof-of-identity token for later"
485 2011-12-01 19:28:32 <wumpus> for the core functionality I agree
486 2011-12-01 19:28:37 <wumpus> but this is just a nice side-feature
487 2011-12-01 19:28:41 <wumpus> probably rarely used
488 2011-12-01 19:29:11 <wumpus> if it turns out this is the big thing everyone wants to do with bitcoin we can always move it to a tab
489 2011-12-01 19:29:14 <Eliel> gmaxwell: yes, hence it would need to be an auxiliary network
490 2011-12-01 19:29:22 <luke-jr> wumpus: this is a core functionality thing
491 2011-12-01 19:30:29 <luke-jr> btw, it would be nice if the connections-meter turned green when it was >=8
492 2011-12-01 19:30:32 <Eliel> gmaxwell: but I'm reasonably convinced this feature will be very important. Mostly because this would allow very secure messaging with very little trouble.
493 2011-12-01 19:30:32 <wumpus> sigh...
494 2011-12-01 19:30:48 <wumpus> luke-jr: yes that'd be nice
495 2011-12-01 19:30:56 <luke-jr> Eliel: nothing here is meant to be encrypted
496 2011-12-01 19:31:03 <Eliel> gmaxwell: simpler user interface than email.
497 2011-12-01 19:31:10 <Eliel> luke-jr: I'm not talking just your feature anymore :P
498 2011-12-01 19:31:22 <wumpus> oh man, yeah let's add secure messaging, why not file transfer now we're add it, and a vpn routing network to avoid censorship
499 2011-12-01 19:31:26 <gmaxwell> Eliel: by little trouble you mean for the user... but actually making a decenteralized p2p messaging system has never been done, I believe.
500 2011-12-01 19:31:56 <luke-jr> wumpus: lol
501 2011-12-01 19:32:00 <gmaxwell> (there are centeralized ones, e.g. icq used to be decenteralized p2p messaging but that didn't go through firewalls so well)
502 2011-12-01 19:32:00 <wumpus> gmaxwell: there's tor messenger, it kind of is that
503 2011-12-01 19:32:22 <gmaxwell> wumpus: true, the thing that uses hidden services for each user.
504 2011-12-01 19:32:27 <wumpus> yep
505 2011-12-01 19:32:34 <wumpus> torchat it's called I see
506 2011-12-01 19:33:10 <Eliel> gmaxwell: well, the only thing that is really needed is the right-click integration for the bitcoin transaction list and that the messaging software can access the bitcoin wallet keys :)
507 2011-12-01 19:33:34 <Eliel> other than that, it could be separate program :)
508 2011-12-01 19:34:20 <gmaxwell> Eliel: I'm not talking about where the program is.. I mean you're presupposing a p2p messaging system of a kind which has almost (*torchat excluded) never existed.
509 2011-12-01 19:35:06 <Eliel> gmaxwell: yes, that's why I'm enthusiastic about the idea. But you're right, it can't start out being integrated deeply into Bitcoin.
510 2011-12-01 19:36:15 <wumpus> yes I'm not saying it's not a good idea, there's probably a lot of people that would like a secure p2p messaging system, but it's pretty orthagonal to bitcoin
511 2011-12-01 19:37:11 <wumpus> and when it exists bitcoin could integrate as a plugin or so
512 2011-12-01 19:37:21 <gmaxwell> Eliel: the torchat thing needs access to the tor hidden services keys too.
513 2011-12-01 19:37:49 <wumpus> yes, it launches its own tor instance
514 2011-12-01 19:37:55 <gmaxwell> (because when you connect to someone you must do a signature to prove that you're who you say you are)
515 2011-12-01 19:38:46 <Eliel> wumpus: orthogonal, yes, I just see great potential with integrating such with bitcoin. If you're going to be keeping a bunch of encryption keys highly secure anyway, might as well just use them for messaging too.
516 2011-12-01 19:38:50 <wumpus> indeed, as tor has no sender address
517 2011-12-01 19:39:28 <Eliel> that way, when you give someone a bitcoin address, you're basically also giving them a mailing address at the same time.
518 2011-12-01 19:40:06 <luke-jr> wumpus: sorry. maybe merging QR code generator is easier for now :P
519 2011-12-01 19:40:19 <wumpus> yes, QR code generator is on the list to be merged
520 2011-12-01 19:40:29 <luke-jr> well, so was signmessage ;)
521 2011-12-01 19:41:09 <wumpus> well yeah I'm not against signmessage
522 2011-12-01 19:41:36 <wumpus> I know it has its uses, I just don't agree with you that it'score functionality :p
523 2011-12-01 19:42:06 <CIA-100> bitcoin: Gavin Andresen master * reb5fff9 / (13 files in 3 dirs): Moved checkpoints out of main, to prep for using them to help prevent DoS attacks - http://git.io/tW10vw
524 2011-12-01 19:42:07 <CIA-100> bitcoin: Gavin Andresen master * r10fd7f6 / (5 files in 2 dirs): Orphan block fill-up-memory attack prevention - http://git.io/s89-zw
525 2011-12-01 19:42:08 <CIA-100> bitcoin: Merge pull request #534 from gavinandresen/DoSorphans
526 2011-12-01 19:42:11 <Eliel> I think being able to easily prove you made a transaction is one quite crucial feature bitcoin needs to have.
527 2011-12-01 19:42:48 <wumpus> yes... but it needs to be usable as well
528 2011-12-01 19:43:00 <luke-jr> gavinandresen: so does that depend on the DoS prevention merge back a while ago?
529 2011-12-01 19:43:08 <gavinandresen> luke-jr: yes
530 2011-12-01 19:43:21 <luke-jr> wumpus: better slightly-unusable than impossible IMO
531 2011-12-01 19:43:30 <luke-jr> wumpus: perfect is the enemy of the good enough
532 2011-12-01 19:43:45 <luke-jr> gavinandresen: so would you say, I should backport both, or neither? :P
533 2011-12-01 19:43:53 <gavinandresen> luke-jr: not impossible, just run -server and use RPC commands to sign.......
534 2011-12-01 19:44:13 <gavinandresen> luke-jr: up to you; I don't have a good sense for how many people are using 0.4.1
535 2011-12-01 19:44:18 <luke-jr> gavinandresen: RPC is for applications.
536 2011-12-01 19:44:48 <gavinandresen> luke-jr: you claimed it was impossible without a GUI, I'm just saying you're wrong.
537 2011-12-01 19:45:04 <wumpus> which is good, as applications know how to format the messages to be signed
538 2011-12-01 19:45:05 <luke-jr> gavinandresen: impossible with just Bitcoin-Qt ;)
539 2011-12-01 19:45:33 <luke-jr> wumpus: so do users, when the website tells them
540 2011-12-01 19:46:04 <luke-jr> before I put up that Bitcoin-Qt with Signmessage, people were getting stuck with it a lot
541 2011-12-01 19:55:33 <Eliel> gavinandresen: for most people it might as well be impossible if it's not in the gui :)
542 2011-12-01 19:56:43 <gavinandresen> Eliel: yup.  I think I'm with wumpus on this one, though, unless it is easier to use it will basically be impossible anyway, even in the GUI.  And more stuff in the GUI makes the app harder for everybody to use.
543 2011-12-01 19:57:03 <luke-jr> gavinandresen: the current implementation is already proven to be usable to some degree
544 2011-12-01 20:02:05 <CIA-100> bitcoin: Gavin Andresen master * rf81ce5b / src/bitcoinrpc.cpp : Speed up RPC authentication (reworked pull from Joel Katz) - http://git.io/CUmBow https://github.com/bitcoin/bitcoin/commit/f81ce5bd6d1008f245a57cb4a1b3c102bacaf530
545 2011-12-01 20:02:06 <CIA-100> bitcoin: Gavin Andresen master * r173efb1 / src/bitcoinrpc.cpp : Merge pull request #670 from gavinandresen/rpcauth_speedup ... https://github.com/bitcoin/bitcoin/commit/173efb1865e271dede53bcdff7ee2e189df07aa4
546 2011-12-01 20:10:37 <denisx> how about adding http://pastebin.com/TFRimLS5 to the CBlock class in main.h and using it in IncrementExtraNonce?
547 2011-12-01 20:11:11 <denisx> it speeds up the treebuild from O(n2-1) to O(logn)
548 2011-12-01 20:11:17 <luke-jr> denisx: make a pull request :p
549 2011-12-01 20:12:05 <makomk> 21:13 <+TimothyA> blk0001.dat is 9GB :|
550 2011-12-01 20:12:12 <makomk> ^ solidcoin lols.
551 2011-12-01 20:14:02 <makomk> Has anyone tested the code that's meant to split the block file at 1GB or wherever it is?
552 2011-12-01 20:18:04 <Eliel> solidcoin blockchain is already at 9GB? whoa.
553 2011-12-01 20:19:36 <makomk> Not exactly. They have a nasty probglem with orphan block spam.
554 2011-12-01 20:26:01 <copumpkin> wait, solidcoin is still alive?
555 2011-12-01 20:27:01 <luke-jr> lol
556 2011-12-01 20:28:56 <_Fireball> night
557 2011-12-01 20:29:12 <makomk> That depends on your definitions of "soldicoin" and "alive"
558 2011-12-01 21:17:23 <[eval]> osmosis: sorry, was testing a little against your bitcoin node (seeing what IP addresses show up in the version message)
559 2011-12-01 21:17:42 <osmosis> np
560 2011-12-01 21:18:10 <osmosis> let me know if you see anything interesting
561 2011-12-01 21:18:54 <[eval]> i'll put it up eventually but it's really just messing around
562 2011-12-01 21:19:04 <osmosis> [eval], ive been wanting to play with bitcoin and python as well. can you point me to any starter code?
563 2011-12-01 21:19:46 <gavinandresen> osmosis: I've got some twisted code here: https://github.com/gavinandresen/Bitcoin-protocol-test-harness
564 2011-12-01 21:19:47 <[eval]> osmosis: i'm staying away from anyone else's code... making mine public domain (specifically, unlicense) so i'm doing clean-room... but i think Abe is in python
565 2011-12-01 21:20:00 <[eval]> oh yeah, that too!
566 2011-12-01 21:20:04 <osmosis> gavinandresen, thx
567 2011-12-01 21:20:05 <[eval]> but i'm still staying away :P
568 2011-12-01 21:20:49 <osmosis> yah, i was talking with the electrum guys about Abe a bit. they use it
569 2011-12-01 21:20:56 <[eval]> yep
570 2011-12-01 21:22:36 <[eval]> i'm writing mainly just a protocol implementation at this point... so i can pass well-formatted messages with ease, and make something similar to transactionradar (but different)
571 2011-12-01 21:26:34 <[eval]> and i can experiment with a few other things
572 2011-12-01 21:26:37 <[eval]> on that note, time to go home
573 2011-12-01 21:36:30 <luke-jr> ]later tell theymos opinion for 0.4.x: should I backport the anti-DoS traps?
574 2011-12-01 21:36:37 <luke-jr> ;;later tell theymos opinion for 0.4.x: should I backport the anti-DoS traps?
575 2011-12-01 21:36:38 <gribble> The operation succeeded.
576 2011-12-01 21:41:57 <md2k7> Can someone explain to me what just happened on the blockchain (blocks 155619, 155620 according to blockexplorer.com)?
577 2011-12-01 21:42:17 <md2k7> Someone found two blocks in succession and announced the second before the first one?
578 2011-12-01 21:42:33 <md2k7> How did the second get accepted before the first one, if it is based on it?
579 2011-12-01 21:42:34 <makomk> Someone's clock is slightly out.
580 2011-12-01 21:43:03 <md2k7> Oh, so the "time" is actually encoded by the miner in the block?
581 2011-12-01 21:43:09 <jrmithdobbs> yes
582 2011-12-01 21:43:30 <md2k7> OK, that explains it... thanks
583 2011-12-01 21:47:48 <gmaxwell> The time is constrained to be at least 1 second after the median of the last 10 blocks, and no further than 2 hours in the future from any node accepting it.
584 2011-12-01 21:47:57 <gmaxwell> But other than that, miners can put whatever time they want there.
585 2011-12-01 21:49:15 <graingert> is there any way to bandwith throttle bitcoin-qt ?
586 2011-12-01 21:49:50 <graingert> as I think it might be intermittently consuming all my upstream connection
587 2011-12-01 21:50:02 <graingert> (can it do that)
588 2011-12-01 21:51:29 <luke-jr> https://bitcointalk.org/index.php?topic=53505.0
589 2011-12-01 21:52:22 <graingert> what are impossible orphan blocks
590 2011-12-01 21:52:41 <luke-jr> graingert: orphan blocks with like difficulty 1
591 2011-12-01 21:52:44 <graingert> valid low-difficulty blocks
592 2011-12-01 21:52:52 <graingert> (maybe built on top of an early part of the block chain)
593 2011-12-01 21:53:40 <graingert> I think an exponential ban would be cool
594 2011-12-01 21:53:57 <luke-jr> graingert: I am not writing new code. Just backporting or not.
595 2011-12-01 21:54:01 <graingert> I know
596 2011-12-01 22:01:50 <luke-jr> gavinandresen: You would be able to answer this best: https://bitcointalk.org/index.php?topic=53505.msg637681#msg637681
597 2011-12-01 22:53:14 <Diablo-D3> dwolla transactions under $10 are now free
598 2011-12-01 23:05:14 <phantomcircuit> Diablo-D3, that makes me highly suspicious
599 2011-12-01 23:05:57 <Diablo-D3> phantomcircuit clearly does not understand volume
600 2011-12-01 23:06:15 <phantomcircuit> lol
601 2011-12-01 23:06:27 <phantomcircuit> WHAT WE LOSE IN SALES WELL MAKE UP IN VOLUME!
602 2011-12-01 23:06:42 <sipa> free * volume = free
603 2011-12-01 23:06:49 <Diablo-D3> exactly
604 2011-12-01 23:06:51 <phantomcircuit> whoooosh
605 2011-12-01 23:06:58 <Diablo-D3> it costs them nothing per transactions
606 2011-12-01 23:07:03 <Diablo-D3> its the big ones that actually do cost them
607 2011-12-01 23:07:39 <phantomcircuit> fedwire charges them per transaction not by amount
608 2011-12-01 23:07:53 <phantomcircuit> so their fee structure is now completely the opposite of what would make sense
609 2011-12-01 23:08:11 <Diablo-D3> phantomcircuit: no
610 2011-12-01 23:08:22 <Diablo-D3> they dont charge them per transaction, they charge them for a bunch of transactions at once
611 2011-12-01 23:36:38 <graingert> !ticker
612 2011-12-01 23:36:38 <gribble> Best bid: 3.07, Best ask: 3.09, Bid-ask spread: 0.02, Last trade: 3.09, 24 hour volume: 61269, 24 hour low: 2.96302, 24 hour high: 3.14