1 2011-06-06 00:01:20 <forrestv> io_error, but they thought that sha-1, and all kinds of arithmetic and string manipulation...
  2 2011-06-06 00:01:28 <forrestv> [were necessary]
  3 2011-06-06 00:01:59 <bd_> forrestv: The idea is transactions should either succeed or not succeed; it's not "succeed depending on X conditions"
  4 2011-06-06 00:02:13 <bd_> this ensures the entire network always agrees on whether the txn completed or not
  5 2011-06-06 00:02:32 <dharmapolice> metonymous_: I'll try.
  6 2011-06-06 00:03:21 <forrestv> bd_, the things i said should be global - block height would be the block the txn got included in
  7 2011-06-06 00:03:28 <forrestv> along with timestamp
  8 2011-06-06 00:04:15 <bd_> forrestv: Now you don't know whether to commit it or not until you see what block it's going in, though. This complicates things for miners significantly; they need to reevaulate EVERY failed transaction every time they start processing a new block
  9 2011-06-06 00:04:46 <bd_> And, really, why would this even be necessary?
 10 2011-06-06 00:04:58 <io_error> bd_: https://en.bitcoin.it/wiki/Contracts
 11 2011-06-06 00:06:38 <forrestv> bd_, yeah, contracts.
 12 2011-06-06 00:06:44 <bd_> io_error: anything based on realtime in bitcoin transactions will have problems with clock drift. There are limits on it, sure, but there's still a bit of leeway. This can cause disagreement on whether a transaction (and by extension, a block) is valid
 13 2011-06-06 00:06:58 <forrestv> base it on a timestamp included in a block
 14 2011-06-06 00:07:16 <bd_> Additionally, if it's implemented as a signature op, then there's no real way to analyze when the transaction will become valid. This means each miner has to simply re-evaluate every rejected txn at every block
 15 2011-06-06 00:07:49 <bd_> Finally, implementing such an op at this point would fork the network
 16 2011-06-06 00:07:53 <io_error> bd_: sure, I know the timestamp is approximate. But supposing you wanted to say, this transaction is not valid before block 135000?
 17 2011-06-06 00:09:29 <bd_> io_error: Well, I guess you'd need an escrow system, right now
 18 2011-06-06 00:10:46 <Matson> charles schumer, NY "It's an online form of money laundering used to disguise the source of money, and to disguise who's both selling and buying"
 19 2011-06-06 00:10:55 <Matson> http://www.nbcnewyork.com/news/local/Schumer-Calls-on-Feds-to-Shut-Down-Online-Drug-Marketplace-123187958.html
 20 2011-06-06 00:12:09 <fizario> lol schumer is probably a dope fiend
 21 2011-06-06 00:12:18 <somecoiner> did 0.3.23 make it out this morning?
 22 2011-06-06 00:13:39 <somecoiner> fizario: Actually, he has dual citizenship... talk about money laundering.
 23 2011-06-06 00:13:53 <fizario> interesting
 24 2011-06-06 00:23:53 <OneFixt> jgarzik: ping
 25 2011-06-06 00:30:02 <jgarzik> OneFixt: pong
 26 2011-06-06 00:30:43 <OneFixt> jgarzik: i installed 0.3.22 but now cannot connect through rpc to getwork
 27 2011-06-06 00:31:04 <OneFixt> have you seen encountered that issue?
 28 2011-06-06 00:31:12 <jgarzik> OneFixt: no
 29 2011-06-06 00:31:27 <luke-jr> jgarzik: it would be neat to get someone on public record offering to provide assitance to law enforcement in tracking down drug dealers using Bitcoin ;)
 30 2011-06-06 00:31:27 <OneFixt> thanks, must be just me
 31 2011-06-06 00:31:50 <luke-jr> jgarzik: someone pro-bitcoin, I mean
 32 2011-06-06 00:32:30 <metonymous_> OneFixt - i found i had to add -server for 0.3.22 and not for 0.3.21
 33 2011-06-06 00:32:39 <luke-jr> I'm not high-profile enough, nor qualified& :p
 34 2011-06-06 00:32:49 <luke-jr> metonymous_: for bitcoind?
 35 2011-06-06 00:32:56 <OneFixt> thanks, i'm running with -server
 36 2011-06-06 00:33:05 <metonymous_> um, i'd have to recheck
 37 2011-06-06 00:33:09 <metonymous_> i just added it to all my scripts
 38 2011-06-06 00:33:26 <metonymous_> and it seemed to take a LONG time to boot 0.3.22 for its first boot
 39 2011-06-06 00:34:33 <somecoiner> metonymous_: does it spin for a minute with IO load before it becomes active?
 40 2011-06-06 00:34:41 <metonymous_> mine did yes
 41 2011-06-06 00:34:48 <metonymous_> probably rescannign the block chain or something
 42 2011-06-06 00:35:08 <somecoiner> 0.3.21 almost always did for me, but 0.3.22 seems better (Linux x86_64)
 43 2011-06-06 00:35:31 <jgarzik> luke-jr: I think speaking at the CIA says volumes
 44 2011-06-06 00:35:54 <luke-jr> jgarzik: CIA doesn't hunt drug dealers, do they?
 45 2011-06-06 00:35:58 <metonymous_> ahhh, i was running rc6, wonder if there are diferences, just switcehd
 46 2011-06-06 00:36:00 <jgarzik> luke-jr: yes
 47 2011-06-06 00:36:08 <luke-jr> oh
 48 2011-06-06 00:36:10 <luke-jr> cool :D
 49 2011-06-06 00:36:35 <metonymous_> spinlocked cpu for about 20 seconds on boot
 50 2011-06-06 00:37:39 <somecoiner> can you strace it when you start it?
 51 2011-06-06 00:41:12 <jrmithdobbs> sipa: have you tested what happens with importwallet/key if you import keys that already exist in the current wallet?
 52 2011-06-06 00:41:53 <metonymous_> bitcoin is reporting that it's working in safe mode
 53 2011-06-06 00:43:14 <somecoiner> what does that imply?
 54 2011-06-06 00:45:48 <somecoiner> "Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain."
 55 2011-06-06 00:46:04 <metonymous_> what should i do?
 56 2011-06-06 00:46:37 <metonymous_> afe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
 57 2011-06-06 00:46:46 <metonymous_> perhaps it's the latter?
 58 2011-06-06 00:46:52 <metonymous_> not a nice message though
 59 2011-06-06 00:46:55 <metonymous_> my RPC has died
 60 2011-06-06 00:47:01 <somecoiner> hom wany connectinos do you currently have?
 61 2011-06-06 00:47:13 <metonymous_> i had 12 before it refused to onnecto
 62 2011-06-06 00:47:15 <metonymous_> i'll ahve a look
 63 2011-06-06 00:47:20 <omes> how exactly is bitcoin decentralized?
 64 2011-06-06 00:47:24 <metonymous_> 10
 65 2011-06-06 00:47:27 <omes> how do you know who to peer with?
 66 2011-06-06 00:47:31 <metonymous_> omes no central authority
 67 2011-06-06 00:47:36 <metonymous_> omes, it uses IRC at  the moment
 68 2011-06-06 00:47:43 <metonymous_> and a list of known "supernodes"
 69 2011-06-06 00:47:46 <metonymous_> but they hope to chang ethat
 70 2011-06-06 00:47:59 <metonymous_> {
 71 2011-06-06 00:48:00 <metonymous_> "balance" : 0.00000000,
 72 2011-06-06 00:48:01 <metonymous_> "generate" : false,
 73 2011-06-06 00:48:02 <somecoiner> metonymous_: it would be connecting to the new numbered boards, right?
 74 2011-06-06 00:48:04 <metonymous_> "genproclimit" : -1,
 75 2011-06-06 00:48:08 <metonymous_> "difficulty" : 434877.04552763,
 76 2011-06-06 00:48:09 <metonymous_> "hashespersec" : 0,
 77 2011-06-06 00:48:09 <omes> metonymous_: how do you connect over irc?
 78 2011-06-06 00:48:12 <metonymous_> "testnet" : false,
 79 2011-06-06 00:48:14 <metonymous_> "keypoololdest" : 1306774292,
 80 2011-06-06 00:48:16 <metonymous_> "paytxfee" : 0.00000000,
 81 2011-06-06 00:48:18 <metonymous_> "errors" : "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
 82 2011-06-06 00:48:20 <metonymous_> }
 83 2011-06-06 00:48:22 <metonymous_> it connects to a channel where IPs are listed
 84 2011-06-06 00:48:24 <metonymous_> afaik
 85 2011-06-06 00:48:25 <omes> hard coded IPs or hostname?
 86 2011-06-06 00:48:26 <metonymous_> and u lodge ur ip there
 87 2011-06-06 00:48:29 <metonymous_> dunno
 88 2011-06-06 00:48:57 <omes> it seems quite easy to shut this down...
 89 2011-06-06 00:49:10 <omes> the supernodes that is
 90 2011-06-06 00:49:16 <metonymous_> and the IRC
 91 2011-06-06 00:49:19 <metonymous_> but the network will remain
 92 2011-06-06 00:49:23 <metonymous_> just new clients won't connect
 93 2011-06-06 00:49:32 <metonymous_> until someone works out a plan
 94 2011-06-06 00:49:39 <metonymous_> or makes a new binary, with a new channel, new supernodes
 95 2011-06-06 00:49:50 <luke-jr> jgarzik: can you recommend anyone to lead the effort? there's a small group joining up in #bitcoin-forensics interested in the idea :D
 96 2011-06-06 00:50:05 <omes> metonymous_: hmmm
 97 2011-06-06 00:50:56 <Nesetalis> so.. friend is trying to run m0mchil's poclbm miner.. and the damn thing is saying it it cant load a pyopencl module..   File "pyopencl_cl.pyo", line 10, in __load \n ImportError: DLL load failed: The specified module could not be found.
 98 2011-06-06 00:50:59 <Nesetalis> however she has the latest drivers
 99 2011-06-06 00:51:43 <metonymous_> ok, my current evaluation is that rc6 is more stable than final
100 2011-06-06 00:51:45 <Nesetalis> is there something else shes missing?
101 2011-06-06 00:56:16 <jrmithdobbs> metonymous_: you should delete your copy of the blockchain, then you should launch with -dnsseed
102 2011-06-06 00:57:29 <jrmithdobbs> metonymous_: assuming you're running >=321
103 2011-06-06 01:00:23 <phantomcircuit> ;;seen MagicalTux
104 2011-06-06 01:00:24 <gribble> MagicalTux was last seen in #bitcoin-dev 12 hours, 55 minutes, and 28 seconds ago: <MagicalTux> Cusipzzz: I do not even know what 1099s is
105 2011-06-06 01:01:02 <somecoiner> lol
106 2011-06-06 01:01:03 <Cusipzzz> lol, I got pinged for that.
107 2011-06-06 01:03:53 <gjs278> http://img194.imageshack.us/img194/9121/screenshotrnb.png why the hell is bitcoind writing so much
108 2011-06-06 01:04:10 <gjs278> answer
109 2011-06-06 01:04:12 <gjs278> debug.log
110 2011-06-06 01:04:25 <phantomcircuit> yeah debug.log is kind of silly in it's verbosity
111 2011-06-06 01:04:47 <somecoiner> is there a no logging flag?
112 2011-06-06 01:05:26 <gjs278> not that I can see
113 2011-06-06 01:05:42 <gjs278> I'm turning it off in my bitcoind though
114 2011-06-06 01:06:14 <gjs278> util.cpp:    // Scroll debug.log if it's getting too big
115 2011-06-06 01:06:16 <gjs278> lol
116 2011-06-06 01:06:43 <phantomcircuit> yeha i love that
117 2011-06-06 01:06:51 <phantomcircuit> it writes like 50 \n
118 2011-06-06 01:08:07 <metonymous_> how do i unsafe mode bitcoin
119 2011-06-06 01:08:36 <somecoiner> looks like the flag was removed for safe mode in 0.3.19 ?
120 2011-06-06 01:09:23 <metonymous_> then i'm confused
121 2011-06-06 01:09:33 <somecoiner> the flag to restrict safe mode, that is
122 2011-06-06 01:09:39 <metonymous_> Tptp&tf.
123 2011-06-06 01:09:44 <metonymous_> keyboard fail
124 2011-06-06 01:09:53 <metonymous_> time to change that passphrase again
125 2011-06-06 01:12:32 <metonymous_> ffs
126 2011-06-06 01:12:42 <metonymous_> fine, lets just hope bitcoin network works it self out
127 2011-06-06 01:12:48 <jrmithdobbs> metonymous_: i told you
128 2011-06-06 01:12:53 <gjs278> -rw-r--r--  1 root root         0 Jun  5 22:10 debug.log
129 2011-06-06 01:12:55 <gjs278> good
130 2011-06-06 01:12:57 <gjs278> and stay that way
131 2011-06-06 01:12:57 <jrmithdobbs> 21:56 < jrmithdobbs> metonymous_: you should delete your copy of the blockchain, then you should launch with -dnsseed
132 2011-06-06 01:12:58 <metonymous_> u id?
133 2011-06-06 01:13:03 <metonymous_> oh
134 2011-06-06 01:13:08 <metonymous_> sorry, i missed that msg
135 2011-06-06 01:13:09 <jrmithdobbs> metonymous_: you need to delete addr.dat as well
136 2011-06-06 01:13:15 <jrmithdobbs> or it'll ignore the seed
137 2011-06-06 01:13:46 <metonymous_> which file is the blockchain?
138 2011-06-06 01:14:01 <metonymous_> blkindex
139 2011-06-06 01:14:04 <metonymous_> blk0001
140 2011-06-06 01:16:42 <metonymous_> thankyou jrmithdobbs
141 2011-06-06 01:16:53 <metonymous_> what did you mean by "ignore the seed"
142 2011-06-06 01:17:21 <jrmithdobbs> metonymous_: once your client is bootstrapped (eg, has been connected even if you were connected to an island like you just were) it prefers previous known peers
143 2011-06-06 01:17:32 <jrmithdobbs> metonymous_: fixes for that will be in 3.23 i think
144 2011-06-06 01:17:59 <metonymous_> so my nodes i connected to weren't connected to the rest of the network?
145 2011-06-06 01:20:02 <jrmithdobbs> ya
146 2011-06-06 01:20:12 <jrmithdobbs> there's a bug that's become a bigger problem because of all the new users recently
147 2011-06-06 01:20:19 <metonymous_> those poor miners
148 2011-06-06 01:20:23 <metonymous_> hoppefully they find me again
149 2011-06-06 01:20:27 <metonymous_> and get my list of nodes
150 2011-06-06 01:20:33 <jrmithdobbs> such a large portion don't have 8333 forwarded and when you connect() it uses the OS default timeout
151 2011-06-06 01:20:44 <jrmithdobbs> which is between 10 minutes and forever depending on the platform
152 2011-06-06 01:21:02 <jrmithdobbs> so you could sit there on an islanded chunk of the network for days and not see a real peer
153 2011-06-06 01:21:13 <metonymous_> that's really sad
154 2011-06-06 01:21:26 <lfm> hehe
155 2011-06-06 01:21:29 <metonymous_> it needs something like dns
156 2011-06-06 01:21:37 <metonymous_> so u can change the ip
157 2011-06-06 01:21:42 <metonymous_> while the hostname stays the same
158 2011-06-06 01:21:46 <jrmithdobbs> nah it mostly needs connect() to timeout
159 2011-06-06 01:21:50 <metonymous_> oh
160 2011-06-06 01:21:54 <jrmithdobbs> and like i said, that'll be fixed in 3.23 pretty sure
161 2011-06-06 01:21:57 <metonymous_> so it goes back to the irc?
162 2011-06-06 01:22:23 <jrmithdobbs> right, when it times out properly it's annoying but it's 10-90 seconds annoying, not 10-90 hours
163 2011-06-06 01:24:18 <metonymous_> well.. that upgrade was painful :(
164 2011-06-06 01:24:28 <metonymous_> next time i'll do the "staging" deployment
165 2011-06-06 01:25:20 <jrmithdobbs> /away IM RICH BITCH
166 2011-06-06 01:25:24 <jrmithdobbs> erm
167 2011-06-06 01:25:26 <metonymous_> hehe
168 2011-06-06 01:25:41 <jrmithdobbs> time to watch some season 1 chappelle ;P
169 2011-06-06 01:37:28 <[Tycho]> jgarzik, hello.
170 2011-06-06 01:37:45 <jgarzik> [Tycho]: hello
171 2011-06-06 01:38:16 <[Tycho]> jgarzik, what do you think about implementing one more protocol kludge ?
172 2011-06-06 01:38:37 <jgarzik> [Tycho]: uh oh :)
173 2011-06-06 01:38:43 <jgarzik> [Tycho]: what's that?
174 2011-06-06 01:39:24 <[Tycho]> I would send only the data field if miner client sends X-Light-Version: 1 header along the getwork request.
175 2011-06-06 01:39:47 <[Tycho]> It's not really an issue with CPU miners, but anyway.
176 2011-06-06 01:39:59 <jgarzik> [Tycho]: create a mask, e.g. "X-Bitcoin-Exclude: data"
177 2011-06-06 01:40:07 <jgarzik> [Tycho]: create a mask, e.g. "X-Bitcoin-Exclude: midstate, target"
178 2011-06-06 01:41:46 <jgarzik> or X-Bitcoin-Include
179 2011-06-06 01:41:48 <[Tycho]> Considering the total hashrate, lots of bandwidth is wasted due to redundant fields.
180 2011-06-06 01:43:01 <jgarzik> [Tycho]: so basically, any mechanism that permits selection of data fields is preferred.  X-Light-Version:1 is too inflexible
181 2011-06-06 01:43:10 <[Tycho]> Good point.
182 2011-06-06 01:43:36 <jgarzik> [Tycho]: 'X-Bitcoin-Include: data' should accomplish your goal
183 2011-06-06 01:44:04 <jgarzik> [Tycho]: some miners may prefer 'X-Bitcoin-Include: data, midstate'
184 2011-06-06 01:44:19 <jgarzik> with a pool, target and hash1 are usually not necessary
185 2011-06-06 01:44:28 <[Tycho]> Ok, i'll try to write some kind of extension description.
186 2011-06-06 01:44:32 <Diablo-D3> uh
187 2011-06-06 01:44:33 <Diablo-D3> what?
188 2011-06-06 01:44:46 <[Tycho]> Oh, another miner author, great :)
189 2011-06-06 01:44:55 <Diablo-D3> stop adding stupid shit goddamned.
190 2011-06-06 01:45:03 <[Tycho]> I just started !
191 2011-06-06 01:45:11 <gjs278> add more
192 2011-06-06 01:45:15 <gjs278> anything to give me more shares
193 2011-06-06 01:45:17 <gjs278> add it
194 2011-06-06 01:45:23 <Diablo-D3> it doesnt give you more shares!
195 2011-06-06 01:45:30 <gjs278> ok
196 2011-06-06 01:45:33 <gjs278> don't add it
197 2011-06-06 01:45:41 <Diablo-D3> the getwork response includes everything you need to mine
198 2011-06-06 01:45:58 <[Tycho]> Acually more than that.
199 2011-06-06 01:46:01 <jgarzik> [Tycho]: BTW, have you tested 'getwork' RPC on 0.3.22-rc or 0.3.22-final?
200 2011-06-06 01:46:12 <Diablo-D3> [Tycho]: it contains three things
201 2011-06-06 01:46:19 <jgarzik> slush: ^^  same question
202 2011-06-06 01:46:29 <[Tycho]> jgarzik, i don't think so. Is there something interesting ?
203 2011-06-06 01:46:37 <Diablo-D3> data, midstate, and target
204 2011-06-06 01:46:44 <luke-jr> jgarzik: I might have, why?
205 2011-06-06 01:47:05 <[Tycho]> I heard that those new versions are less stable.
206 2011-06-06 01:47:14 <jgarzik> [Tycho]: yes, lowering TX fees greatly
207 2011-06-06 01:47:28 <Diablo-D3> [Tycho]: now, out of those three, what could you possibly remove?
208 2011-06-06 01:47:38 <jgarzik> luke-jr: just looking for positive/negative feedback on field deployments for pools
209 2011-06-06 01:47:38 <[Tycho]> Diablo-D3, target
210 2011-06-06 01:47:42 <Diablo-D3> need target.
211 2011-06-06 01:47:48 <luke-jr> jgarzik: do you want my rev id?
212 2011-06-06 01:47:52 <jgarzik> [Tycho]: bug reports welcome...
213 2011-06-06 01:48:00 <Diablo-D3> [Tycho]: you cant remove it otherwise how does the miner know what to look for?
214 2011-06-06 01:48:07 <[Tycho]> jgarzik, but how the TX fees is related to pool use ?
215 2011-06-06 01:48:31 <[Tycho]> Diablo-D3, it can request one full work and then just the data field in next getworks.
216 2011-06-06 01:48:41 <Diablo-D3> thats stupid
217 2011-06-06 01:48:45 <[Tycho]> Also it may assume that difficulty 1 is default.
218 2011-06-06 01:48:47 <Diablo-D3> it also makes miners more complex
219 2011-06-06 01:48:51 <jgarzik> [Tycho]: miners with older code may refuse to relay or mine TX's with the newer fees
220 2011-06-06 01:48:53 <Diablo-D3> yes, but WHICH difficulty 1?
221 2011-06-06 01:48:53 <[Tycho]> Is optional/
222 2011-06-06 01:48:55 <luke-jr> Diablo-D3: optionally
223 2011-06-06 01:48:59 <Diablo-D3> some pools are fucktarded and do H==0.
224 2011-06-06 01:49:10 <jgarzik> [Tycho]: 0.01 is too expensive
225 2011-06-06 01:49:29 <Diablo-D3> Im glad everyone is going to be using my pool when I get it finished
226 2011-06-06 01:49:29 <[Tycho]> jgarzik, my pool accepts free TXs. Sometimes lots of them.
227 2011-06-06 01:49:33 <Diablo-D3> none of this retarded shit.
228 2011-06-06 01:49:53 <Diablo-D3> no more pushpool, no more deepbit domination
229 2011-06-06 01:49:53 <jgarzik> [Tycho]: it would be really nice to have agreement on fees
230 2011-06-06 01:50:02 <jgarzik> [Tycho]: otherwise it is chaotic for users
231 2011-06-06 01:50:15 <luke-jr> jgarzik: Eligius has always accepted the new fees ;)
232 2011-06-06 01:50:16 <gmaxwell> [Tycho]: do you accept unlimited free txn? (e.g. when the block goes over 4k?)
233 2011-06-06 01:50:28 <[Tycho]> Usually I include 4-200 Kbs of free txses. Should be around 100k ATM.
234 2011-06-06 01:51:00 <[Tycho]> I set it looking at current situation.
235 2011-06-06 01:51:01 <jgarzik> [Tycho]: and how does your node handle fees?  are TX priority boosted, as block fills up, if fee paid?
236 2011-06-06 01:51:09 <gmaxwell> [Tycho]: in any case, the change just increases what counts as paid from thing with at least 0.01 in fees to 0.0005 which is more aligned with the current exchange rates.
237 2011-06-06 01:51:53 <Diablo-D3> why not just sort by (tx fee, btc amount)?
238 2011-06-06 01:52:07 <[Tycho]> I don't remember if I changed the priority part. Usually my blocks never are up to the capacity.
239 2011-06-06 01:52:51 <[Tycho]> The only time when some of them were full is the flood a couple of months ago.
240 2011-06-06 01:52:59 <gmaxwell> Diablo-D3: because priority is a better metric than btc amount.
241 2011-06-06 01:53:17 <jgarzik> [Tycho]: can you post a clear statement on your pool's fee behavior?
242 2011-06-06 01:53:34 <Diablo-D3> gmaxwell: I listed two columns there, dude.
243 2011-06-06 01:53:37 <jgarzik> [Tycho]: this is a big issue for bitcoin users, as you have a very large % of hash power
244 2011-06-06 01:53:44 <gmaxwell> Diablo-D3: it includes the value, the age, and the tx_data size which hits every major DOS angle.
245 2011-06-06 01:53:56 <gmaxwell> Diablo-D3: and I'm saying your second column sucks. :)
246 2011-06-06 01:54:02 <Diablo-D3> gmaxwell: but if Im a pool, I only care about tx fees
247 2011-06-06 01:54:05 <Diablo-D3> I want as much as possible
248 2011-06-06 01:54:16 <gmaxwell> Diablo-D3: sure, so do (fee, priority)
249 2011-06-06 01:54:27 <Diablo-D3> yes, but priority sounds a lot like what I just said
250 2011-06-06 01:54:30 <[Tycho]> jgarzik, I did a forum post about it. I will support free txses as long as it don't gets in the way of mining.
251 2011-06-06 01:54:34 <Diablo-D3> (fee, btc amount)
252 2011-06-06 01:54:42 <[Tycho]> I like free TXses.
253 2011-06-06 01:54:56 <gmaxwell> Diablo-D3: priority is not btc amount. priority includes the value, the age, and the tx_data size which hits every major DOS angle.
254 2011-06-06 01:55:01 <jgarzik> [Tycho]: can you be more specific about what happens when a user pays a fee?
255 2011-06-06 01:55:05 <Diablo-D3> gmaxwell: you said that.
256 2011-06-06 01:55:12 <Diablo-D3> gmaxwell: but heres the big issue
257 2011-06-06 01:55:13 <gmaxwell> Diablo-D3: Indeed.
258 2011-06-06 01:55:17 <Diablo-D3> does bitcoin, by default, do this?
259 2011-06-06 01:55:23 <gmaxwell> Diablo-D3: Yes.
260 2011-06-06 01:55:23 <[Tycho]> I know that system will use fees instead of generation bonus, but this is not needed yet.
261 2011-06-06 01:55:28 <Diablo-D3> shits fine then
262 2011-06-06 01:55:46 <Diablo-D3> also
263 2011-06-06 01:55:49 <Diablo-D3> it needs one more rool
264 2011-06-06 01:56:03 <Diablo-D3> since we're pools
265 2011-06-06 01:56:08 <[Tycho]> jgarzik, I'm getting this fee. Are you asking if it's divided amongst pool users ?
266 2011-06-06 01:56:12 <Diablo-D3> prioritize our own no-fee tx above all
267 2011-06-06 01:56:27 <jgarzik> [Tycho]: no, the behavior bitcoin users will receive from your miner, when paying a fee.
268 2011-06-06 01:57:09 <[Tycho]> jgarzik, I'll check it. Last time I touched this code was during the flood.
269 2011-06-06 01:57:27 <phantomcircuit> THE GREAT FLOOD
270 2011-06-06 01:58:07 <[Tycho]> "<jgarzik> [Tycho]: it would be really nice to have agreement on fees" - what's your idea about this ?
271 2011-06-06 01:58:55 <Diablo-D3> hey [Tycho]
272 2011-06-06 01:59:05 <Diablo-D3> does bitcoin prioritize our own tx above all?
273 2011-06-06 01:59:57 <[Tycho]> Sometimes.
274 2011-06-06 02:00:15 <[Tycho]> Are you talking about stock bitcoind or my customized one ?
275 2011-06-06 02:00:25 <gmaxwell> [Tycho]: It's useful for bitcoin users to know if they set fee X for txn Y they'll get behavior Z. Since there are many different non-disclosed polices for this, it's hard to give a concrete answer.
276 2011-06-06 02:00:26 <jgarzik> [Tycho]: we are seeking consensus on the forums for a TX fee schedule that is supported by miners and clients both
277 2011-06-06 02:00:31 <Diablo-D3> [Tycho]: stock
278 2011-06-06 02:00:40 <jgarzik> [Tycho]: otherwise it is inconsistent message and behavior for users
279 2011-06-06 02:00:41 <[Tycho]> Diablo-D3, i think that it doesn't.
280 2011-06-06 02:00:49 <Diablo-D3> [Tycho]: thats dangerous for pool users
281 2011-06-06 02:01:01 <Diablo-D3> because the pool would be stalling on payouts
282 2011-06-06 02:01:18 <[Tycho]> But i'm not using the stock one.
283 2011-06-06 02:01:24 <Diablo-D3> my users would be
284 2011-06-06 02:01:48 <[Tycho]> jgarzik, it would be cool if users could cancel the transactions and try again with another fee value. But this can't be made easy :(
285 2011-06-06 02:02:00 <Diablo-D3> well no
286 2011-06-06 02:02:06 <Diablo-D3> you should be able to list, say, a max fee
287 2011-06-06 02:02:19 <Diablo-D3> and get the excess back in change
288 2011-06-06 02:02:41 <jgarzik> [Tycho]: sure it can.  1) expire TX from cache after 144 blocks, 2) client stops resending when they wish, if TX continues not to be confirmed
289 2011-06-06 02:02:59 <[Tycho]> 144 is not that fast :)
290 2011-06-06 02:03:01 <gmaxwell> [Tycho]: Better would be just spending the unconfirmed coin in a TX with a fee, and letting that fee pay for the prior txn too.
291 2011-06-06 02:03:14 <gmaxwell> (not exactly a replacement, but more generally useful)
292 2011-06-06 02:03:52 <jgarzik> [Tycho]: so we live with the network we have today...  where clients will not even relay some transactions without fees
293 2011-06-06 02:04:02 <gmaxwell> In a lot of cases the inputs would be different if the fee was different, so I don't see it being easy e.g. to catch a replacement txn and handle it correctly.
294 2011-06-06 02:04:35 <[Tycho]> jgarzik, I understand the idea about the consensus. I'll think about it. Currently I'm trying to make all free TXes deliverable.
295 2011-06-06 02:05:43 <Diablo-D3> you know whats sad?
296 2011-06-06 02:05:49 <Diablo-D3> my pool software is better than deepbits :D
297 2011-06-06 02:06:09 <phantomcircuit> you know what's sad?
298 2011-06-06 02:06:13 <phantomcircuit> tvtorrents.com is down
299 2011-06-06 02:06:18 <neopallium> what if miners published (to the network) the minimal TX fee that they will accept, then the bitcoin client can display a recommended minimal TX fee, based on how likely the TX will be accepted.
300 2011-06-06 02:07:08 <phantomcircuit> neopallium, how you you know it's only from miners?
301 2011-06-06 02:07:11 <Diablo-D3> phantomcircuit: just use eztv.it instead
302 2011-06-06 02:07:22 <MasterChief> phantomcircuit ;_;
303 2011-06-06 02:07:26 <phantomcircuit> i dont like them
304 2011-06-06 02:07:33 <phantomcircuit> shits always slow
305 2011-06-06 02:07:42 <phantomcircuit> hey wtf that doesn't work wither
306 2011-06-06 02:07:58 <[Tycho]> neopallium, the transaction may not be relayed to the miners.
307 2011-06-06 02:08:12 <phantomcircuit> Diablo-D3, ZOMG IS THE WORLD ENDING
308 2011-06-06 02:09:10 <Diablo-D3> phantomcircuit: oh?
309 2011-06-06 02:09:57 <io_error> isohunt.com
310 2011-06-06 02:10:08 <gmaxwell> neopallium: Client could make a guess based on the last 144 blocks though.
311 2011-06-06 02:10:11 <phantomcircuit> also the pirate bay tracker is never fucking up but is on all the torrents
312 2011-06-06 02:10:16 <phantomcircuit> it's annoying as all hell
313 2011-06-06 02:10:56 <neopallium> the miners/block generators can include there min. fee value in the blocks they generate.
314 2011-06-06 02:11:20 <neopallium> then the client can get those hints from the last x blocks.
315 2011-06-06 02:11:27 <gmaxwell> neopallium: doesn't matter if the TXN is never forwarded to them.
316 2011-06-06 02:11:35 <phantomcircuit> Error 137 (net::ERR_NAME_RESOLUTION_FAILED): Unknown error.
317 2011-06-06 02:11:36 <phantomcircuit> argh
318 2011-06-06 02:11:39 <luke-jr> gmaxwell: that idea has flaws too
319 2011-06-06 02:12:04 <luke-jr> gmaxwell: how can the client tell if the txn with a lower fee has an off-network contract with the miner?
320 2011-06-06 02:12:10 <gmaxwell> neopallium: instead the clients should just observe what makes it into blocks, then make a reasonable guess. But as luke-jr is about to say, miners giving free passes to some users screws that up
321 2011-06-06 02:12:33 <neopallium> I am just thinking of ways for the network to self stabilize on an accepted TX fee range.
322 2011-06-06 02:12:58 <gmaxwell> or the users in the mined blocks used an alternative transport to reach the miner rather than the public p2p net.
323 2011-06-06 02:13:01 <anarchyx> ;;bc,stats
324 2011-06-06 02:13:01 <fizario> fees can be paid out on a sliding scale based on how fast tx are being processed... gives an incentive to process them quickly :)  of course that requires some sort of vote to determine performance... (or a third-party managed fund)
325 2011-06-06 02:13:03 <gribble> Current Blocks: 128927 | Current Difficulty: 434882.7217497 | Next Difficulty At Block: 129023 | Next Difficulty In: 96 blocks | Next Difficulty In About: 11 hours, 8 minutes, and 48 seconds | Next Difficulty Estimate: 557933.99072592
326 2011-06-06 02:13:16 <phantomcircuit> lol wtf dns is blocked
327 2011-06-06 02:13:35 <jgarzik> you left out omg, bbq and ponies
328 2011-06-06 02:13:39 <gmaxwell> phantomcircuit: ISPs luv you using their special dns with search redirection.
329 2011-06-06 02:13:52 <phantomcircuit> gmaxwell, it worked yesterday
330 2011-06-06 02:13:55 <phantomcircuit> :/
331 2011-06-06 02:13:59 <luke-jr> gmaxwell: perhaps what might work is, based on the user's choice, automatically increasing the fee as it gets ignored
332 2011-06-06 02:14:05 <gmaxwell> phantomcircuit: to avoid that I've done DNS to recursive resolvers over v6 in the past. (until I could change ISPs)
333 2011-06-06 02:14:05 <slush> jgarzik, shortly, because I'm hurry: I use stock settings for fees, didn't tested .22 yet, but affraid that it will broke some performance patches I've applied for block generation.
334 2011-06-06 02:14:25 <gmaxwell> luke-jr: it's hard to replace the transaction.
335 2011-06-06 02:14:34 <luke-jr> gmaxwell: dunno, they have versions already
336 2011-06-06 02:14:37 <phantomcircuit> gmaxwell, cant setup ipv6 the router is in polish lol
337 2011-06-06 02:14:40 <jgarzik> slush: any chance those patches can go into upstream?
338 2011-06-06 02:14:42 <gmaxwell> phantomcircuit: HAHA
339 2011-06-06 02:14:44 <neopallium> what is the new min. fee in the latest bitcoin client code? (the official one)
340 2011-06-06 02:14:45 <luke-jr> so tx "A" v2 supercedes tx "A" v1
341 2011-06-06 02:14:56 <gmaxwell> neopallium: it's not a "min fee".
342 2011-06-06 02:15:14 <slush> jgarzik: they are published by m0mchil on forum. But it is considered as ugly patch rather than 'final solution'
343 2011-06-06 02:15:20 <gmaxwell> neopallium: it's a "min fee for very low priority txn" and it's 0.0005 (vs 0.01)
344 2011-06-06 02:15:23 <jgarzik> neopallium: 0.3.22 relays/mines the 0.0005 BTC
345 2011-06-06 02:15:34 <fizario> then miners have an incentive to wait for the user to up his fee till its worthy enough...
346 2011-06-06 02:15:35 <jgarzik> neopallium: free TX's are still free
347 2011-06-06 02:16:10 <jgarzik> fizario: miners also have an incentive to provide a useful network for users
348 2011-06-06 02:16:27 <fizario> jgarzik: true.. while maximally benefitting themselves with the most fees possible hehe
349 2011-06-06 02:16:29 <neopallium> ah, I though some clients on the network where rejecting TXs that had no fee (i.e. free)
350 2011-06-06 02:16:29 <slush> jgarzik: it is about making getwork non-blocking while processing new txes
351 2011-06-06 02:16:30 <gmaxwell> It kinda sucks that new users almost always have a very low priority txn as their first txn... and also have little enough bitcoin that a fee sounds high.
352 2011-06-06 02:16:46 <phantomcircuit> neopallium, there are
353 2011-06-06 02:16:55 <jgarzik> gmaxwell: yes
354 2011-06-06 02:17:19 <jgarzik> neopallium: if the value is below 0.01, most clients/miners will not relay without a fee
355 2011-06-06 02:17:24 <phantomcircuit> Diablo-D3, zomg the world is endinng the .it dns servers appear to be fucked
356 2011-06-06 02:17:26 <phantomcircuit> lololol
357 2011-06-06 02:17:54 <Diablo-D3> .... goddamnit italy
358 2011-06-06 02:18:03 <phantomcircuit> oh it's the eztv.se servers
359 2011-06-06 02:18:17 <neopallium> clients that relay TXs get part of the fee?  I though the fee only went to the miners/pools
360 2011-06-06 02:18:25 <gmaxwell> Also, I suspect that there is some bug in the priority calculation in .21 ... some random person in #bitcoin had to wait >>12 hours (I think they eventually sent at about 26) to send a simple 1BTC transaction (1 in, 1 out) with no fee.
361 2011-06-06 02:18:42 <gmaxwell> neopallium: the relay behavior is to stop network flooding, not to provide income.
362 2011-06-06 02:18:54 <neopallium> ok
363 2011-06-06 02:19:12 <Diablo-D3> phantomcircuit: yeah apparently its up and down lately
364 2011-06-06 02:20:04 <phantomcircuit> I NEED MY AMERICAN TV
365 2011-06-06 02:20:10 <phantomcircuit> lol
366 2011-06-06 02:22:17 <fizario> is there a list rating miners based on what % of tx were left out the block
367 2011-06-06 02:23:09 <jrmithdobbs> phantomcircuit: you have any idea the significance behind the magic numbers in EncodeBase58() in base58.h ?
368 2011-06-06 02:23:24 <jrmithdobbs> phantomcircuit: str.reserve((pend - pbegin) * 138 / 100 + 1);
369 2011-06-06 02:24:28 <jrmithdobbs> +1 is for '\0', pend -pbegin is the length of the original little endian unsigned char storage, but wtf does * 138/100 come from?
370 2011-06-06 02:24:56 <jrmithdobbs> or anyone, for that matter
371 2011-06-06 02:25:42 <gmaxwell> fizario: considering that you can't tell who mind what block no.
372 2011-06-06 02:26:04 <fizario> another way is to make it a lottery - each free tx is a lottery ticket whose payout is revealed in +5 blocks... (deterministically, but hard to predict)..  this gives miners a huge incentive to include as many tx as possible to win the lottery :)
373 2011-06-06 02:26:07 <gmaxwell> fizario: (I mean, you can sometimes tell eligius blocks are obvious, and BTC guild links to all theirs in public)...
374 2011-06-06 02:27:24 <gmaxwell> fizario: That not great either. What happens when I start spamming the network with thousands of dust-sized txns an hour. ... and then all mined blocks are 1MB...
375 2011-06-06 02:27:54 <fizario> yes, you would need to have it be based on the ratio of free to paid or something
376 2011-06-06 02:27:59 <gmaxwell> fizario: also, depending on how you did the lottery, miners would dustspam themselves.
377 2011-06-06 02:28:02 <fizario> or take a vote of all miners in history
378 2011-06-06 02:28:06 <jrmithdobbs> no voting
379 2011-06-06 02:28:09 <jrmithdobbs> voting is bad
380 2011-06-06 02:28:21 <gmaxwell> voting = sybil attacks, generally
381 2011-06-06 02:28:47 <gmaxwell> plus voting power is non-linear when the participants are weighed.
382 2011-06-06 02:28:48 <fizario> if the voters are only succesful miners, they represent actual computation
383 2011-06-06 02:29:13 <jrmithdobbs> fizario: that's even worse
384 2011-06-06 02:29:29 <jrmithdobbs> now you're encouraging consilidation on a large scale
385 2011-06-06 02:29:36 <gmaxwell> fizario: dunno why you're so concerned with free transactions.
386 2011-06-06 02:29:46 <ezl> what timezone are mtgox timestamps in?
387 2011-06-06 02:29:55 <fizario> not consolidation, just maximizing the # of tx performance monitors
388 2011-06-06 02:30:13 <jrmithdobbs> ezl: utc
389 2011-06-06 02:30:55 <fizario> if you incentivize tx throughput, everyone prospers
390 2011-06-06 02:31:33 <gmaxwell> Then it's incentivized already.
391 2011-06-06 02:31:35 <ezl> thanks jrmithdobbs
392 2011-06-06 02:31:41 <gmaxwell> Becuase bitcoin prospering helps everyone involved.
393 2011-06-06 02:32:16 <gmaxwell> fizario: you're ignoring the fact that free txn can easily be dustspam. It has been in the past when it wasn't handled as well as it is now.
394 2011-06-06 02:32:23 <fizario> right.. but already pools are pushing back declaring theyll only accept certain fee levels. they will try to negotiate the highest tx's possible by penalizing "free-loaders"
395 2011-06-06 02:32:31 <fizario> or low-bidders
396 2011-06-06 02:32:37 <gmaxwell> fizario: No, you're misunderstanding what pools are doing
397 2011-06-06 02:32:40 <amid_hasan> hello
398 2011-06-06 02:33:06 <gmaxwell> luke-jr isn't making bank on a fee of 0.00004096
399 2011-06-06 02:33:27 <gmaxwell> fizario: the reason for imposing a fee is so that non-spammers identify themselves in advance of spam existing.
400 2011-06-06 02:33:31 <jrmithdobbs> fizario: did you not read the paper? incentivizing txn inclusion through fees is the point of the system
401 2011-06-06 02:33:49 <jrmithdobbs> well, one of them
402 2011-06-06 02:33:51 <luke-jr> gmaxwell: in advance? spam has been clogging the network for months
403 2011-06-06 02:34:20 <fizario> jrmithdobbs: fees on individual tx isn't the only way to do it. the goal is total tx throughput.
404 2011-06-06 02:34:29 <gmaxwell> luke-jr: Yes, and yet people still aren't paying fees to get ahead of it. Which is their own weird ass choice.
405 2011-06-06 02:34:42 <gmaxwell> fizario: throughput is not goodput
406 2011-06-06 02:35:09 <fizario> game theory predicts miners will price discriminate: at each round a small % of users (lowest percentile say) will be excluded until they increase their fees
407 2011-06-06 02:35:10 <gmaxwell> Making all blocks maximum size with junk txn would be maximal throughput. but it would be terrible for bitcoin.
408 2011-06-06 02:35:13 <jrmithdobbs> fizario: and large mining ops are always going to prioritize txns with fees
409 2011-06-06 02:36:42 <jgarzik> jrmithdobbs: the largest mining op right now is all about free TX's, scroll up.
410 2011-06-06 02:36:54 <gmaxwell> He did say prioritize.
411 2011-06-06 02:36:58 <fizario> right the way to avoid spam free tx is to look at the median ratio of fee to non-fee and penalize deviations that are discriminatory
412 2011-06-06 02:37:06 <jrmithdobbs> jgarzik: i said prioritize. not ignore free txns
413 2011-06-06 02:37:14 <gmaxwell> fizario: Parse failure.
414 2011-06-06 02:44:53 <amid_hasan> is there a way to install bitcoin on the BlackBerry PlayBook?:
415 2011-06-06 02:45:06 <lfm> amid_hasan: no
416 2011-06-06 02:45:16 <amid_hasan> lfm: why not. isn't it open-sourced?
417 2011-06-06 02:45:31 <jrmithdobbs> so port it
418 2011-06-06 02:45:34 <lfm> amid_hasan: ya but its not proted to it yet
419 2011-06-06 02:45:39 <lfm> ported
420 2011-06-06 02:45:40 <jrmithdobbs> so you and the 5 other people with them and no email can do something useful
421 2011-06-06 02:45:48 <fizario> you can use mybitcoin or rpc to your server
422 2011-06-06 02:45:53 <amid_hasan> what do you mean by no email?
423 2011-06-06 02:46:19 <lfm> jrmithdobbs: blackberry invented email you know
424 2011-06-06 02:46:56 <jrmithdobbs> lfm: pretty ironic
425 2011-06-06 02:47:10 <fizario> gmaxwell: there are ways around it...  in the first case successful miners vote on how many tx were left out. compare to previous blocks. then fees are paid out to scale based on that metric..    or you just have miners fork when they detect too many blocks being left out
426 2011-06-06 02:47:27 <amid_hasan> jrmithdobbs: your comment about playbook not having email is just ill-researched
427 2011-06-06 02:47:34 <amid_hasan> i send email from the device daily
428 2011-06-06 02:47:50 <fizario> then theres no incentive to discriminate against certain tx.. however, if there arent enough fees, no one will mine, so users will still pay fees
429 2011-06-06 02:47:52 <gmaxwell> fizario: great, so I generate 1000 txn per minute in spam, and the network forks against anyone smart enough to ignore my attack
430 2011-06-06 02:47:52 <lfm> fizario: huh?
431 2011-06-06 02:47:57 <jrmithdobbs> a company famous for their (shitty half-assed but only thing available at the time) push email requiring you to have a second device paired with it to use email is just hilarious
432 2011-06-06 02:48:15 <amid_hasan> and i also have a phone which takes in email. don't understand why i need to be checking the same email on 50 devices??
433 2011-06-06 02:48:15 <jrmithdobbs> fizario: voting is retarded
434 2011-06-06 02:48:52 <fizario> gmaxwell: lol no, the miners still agree on minimum throughput required. they wouldnt require gigabytes of tx
435 2011-06-06 02:48:58 <amid_hasan> do you check your email on your iphone/ipad, and stare at your ipad for 14 hours a day?
436 2011-06-06 02:49:18 <gmaxwell> fizario: I don't know why you think _zero_ fee txns are especially desirable. They're useful for making the system friendly to newbies, but thats about it.
437 2011-06-06 02:49:24 <gmaxwell> fizario: okay, thats almost sounding reasonable.
438 2011-06-06 02:49:37 <lfm> gmaxwell: same as email
439 2011-06-06 02:49:42 <gmaxwell> fizario: but it's all unneeded as soon as there is any fee at all.
440 2011-06-06 02:49:50 <gmaxwell> lfm: email is increasingly useless because of spam
441 2011-06-06 02:50:06 <gmaxwell> lfm: and the spam filtering is often as bad as the illness it cures.
442 2011-06-06 02:50:37 <lfm> spam email has been nearly constant for years, not increasing
443 2011-06-06 02:50:58 <fizario> there are some restaurants where you pay what you can afford.. surprisingly they still make good profit.  in a world where you pay whatever fee you can lots of ppl can do free frictionless tx, but still enough ppl pay to keep the system alive (if no one pays, system failure ensues, so the most committed users will still have it in their interest to use fees)
444 2011-06-06 02:51:51 <lfm> fizario: and so long as txn with fees get priority it should work no prob
445 2011-06-06 02:52:30 <jrmithdobbs> fizario: you're fixing a non-existant problem
446 2011-06-06 02:52:43 <fizario> indeed. just worried about strategic discrimination against the lowest fees - a way to coerce them into paying more
447 2011-06-06 02:52:51 <jrmithdobbs> well, you'd actually be making the problem you're arguing against a bigger one, but i'm bored of this discussion
448 2011-06-06 02:52:56 <JFK911> ;;bc,mtgox
449 2011-06-06 02:52:57 <gribble> {"ticker":{"high":18.3987,"low":16.2,"vol":25818,"buy":17.868,"sell":17.999,"last":17.8672}}
450 2011-06-06 02:53:28 <gmaxwell> fizario: well, I've worried about it to. But right now its a non-issue because all miners want bitcoin to be successful
451 2011-06-06 02:53:39 <gmaxwell> fizario: and nickle and diming people on fees won't get it there
452 2011-06-06 02:53:45 <fizario> indeed
453 2011-06-06 02:53:54 <jrmithdobbs> fizario: this is a commodity/currency system. not a charity?!
454 2011-06-06 02:54:06 <gmaxwell> fizario: it'll be a different question if/when bitcoin's success looks upstoppable.
455 2011-06-06 02:54:08 <fizario> haha.. welcome comrade
456 2011-06-06 02:54:30 <lfm> and without any special changes there are more and more fees in the blocks every day it seems
457 2011-06-06 02:55:02 <gmaxwell> lfm: don't be so happy. This is mostly per-KB fees from bloated txn.
458 2011-06-06 02:55:14 <lfm> works for me
459 2011-06-06 02:55:17 <gmaxwell> lfm: people paying 70 BC out of mostly >0.1 inputs. :-/
460 2011-06-06 02:55:21 <jrmithdobbs> and people getting annoyed with the p2p network latency
461 2011-06-06 02:55:23 <gmaxwell> s/BC/BTC/
462 2011-06-06 02:55:23 <jrmithdobbs> heh
463 2011-06-06 02:56:03 <lfm> it is as it should be. free txn may take longer (ie overnight)
464 2011-06-06 02:56:18 <gmaxwell> It's hard to educate joe-miner that they actually want to increase the minimum payouts on the pools they use.
465 2011-06-06 02:57:09 <lfm> gmaxwell: ya the pool admins should take a hard line on that and pay out no more than daily
466 2011-06-06 02:58:23 <gmaxwell> Eligius does 1BTC threshold (and only when it finds a block). I think BTCGuild will be changing to maximum once/day, I think. So some do.
467 2011-06-06 02:59:57 <amid_hasan> what language is the source in?
468 2011-06-06 03:00:43 <lfm> amid c++
469 2011-06-06 03:01:49 <amid_hasan> can I port to a web language?
470 2011-06-06 03:01:57 <jrmithdobbs> go for it
471 2011-06-06 03:02:03 <lfm> you can do whatever you want
472 2011-06-06 03:02:25 <amid_hasan> server side, where should i host?
473 2011-06-06 03:02:48 <lfm> doesnt really matter to us
474 2011-06-06 03:02:56 <jrmithdobbs> you should probably get the code working before you worry about that
475 2011-06-06 03:03:49 <lfm> do a host with a ati/amd gpu and then you could also mine on it
476 2011-06-06 03:04:16 <fizario> by the way, users can revolt against dictatorial miners by adding all pending tx as dependencies of their tx (through some new script or sorted-input hash). to be included in the block, all the referenced tx's have to be included as well. those who pay fees will have an incentive to do it, since they know theyll want to use free tx later and want to keep fees at equilibrium
477 2011-06-06 03:05:24 <lfm> fizario: ya, it would require custom clients to generate such txns since the standard client doesnt allow you to choose what btc input go into yourtxn
478 2011-06-06 03:05:33 <gmaxwell> fizario: you can't use someone elses txn as a dependency.
479 2011-06-06 03:05:43 <gmaxwell> And the miners should be smart enough to groom up dependencies.
480 2011-06-06 03:05:59 <gmaxwell> If someone sends me a free txn that gets stuck, I should be able to unstick it by spending it with a reasonable fee.
481 2011-06-06 03:06:21 <fizario> rite.. not currently. requires a new script that says: "must appear in a block with these 5 tx". if you pick the 5 at random, the superset would be most of the pending tx
482 2011-06-06 03:06:22 <lfm> dependancies generally will just lower you priority anyway, not raise it I think
483 2011-06-06 03:06:51 <gmaxwell> lfm: it would let someone else pay the fee for some other txn.
484 2011-06-06 03:07:23 <gmaxwell> fizario: not 'in a block with' but confirmed with/after, no?
485 2011-06-06 03:07:26 <fizario> the miner wouldnt object to the free-loaders, since it wants the tx fee on the leader tx
486 2011-06-06 03:07:41 <lfm> I dunno if a miner would raise the priority of a free txn in order to claim a fee on a txn that is dependant on the free one.
487 2011-06-06 03:07:43 <fizario> gmaxwell: yeah - those tx must exist before this one pays a fee
488 2011-06-06 03:07:58 <gmaxwell> It would be nice if someone would fix the dependency grooming for the normal stuff with those crazy dependant txn.
489 2011-06-06 03:08:09 <gmaxwell> lfm: why not?
490 2011-06-06 03:08:24 <gmaxwell> lfm: Just treat them as one big txn and apply the same fee rules.
491 2011-06-06 03:08:35 <lfm> gmaxwell: dunno it just could get counter productive
492 2011-06-06 03:08:52 <gmaxwell> lfm: it's actually important (ignoring fizario's weird third party ones)
493 2011-06-06 03:08:57 <fizario> at btc=$100 there will be a lot more optimization happening hehe
494 2011-06-06 03:09:06 <lfm> maybe, seems like its getting too complex then
495 2011-06-06 03:09:15 <gmaxwell> lfm: right now an unconfirmed txn in your wallet can screw up a txn you send even with nice fees.
496 2011-06-06 03:09:47 <gmaxwell> lfm: I've posted some examples of this where txn with biiigg fees took days because there was a stupid unconfirmed 0.01 used as an input.
497 2011-06-06 03:10:12 <lfm> gmaxwell: ya, that would need smarter miners to dig for those fees
498 2011-06-06 03:10:46 <gmaxwell> little worse when the smart miner may not have even heard of the parent txn because of forwarding rules though, alas.
499 2011-06-06 03:10:57 <lfm> and a spammer could send 1000s of txn then with just a small fee
500 2011-06-06 03:11:33 <gmaxwell> lfm: nah, apply the same aggregate fee rules. XX per KB with a floor of 1KB per involved TXN, for example
501 2011-06-06 03:11:43 <gmaxwell> so it's never cheaper to do it that way.
502 2011-06-06 03:12:13 <lfm> yup, just seems like it complex enuf that it will be buggy no matter how you do it
503 2011-06-06 03:19:17 <anarchyx> guys at which point will you sell half your stach and retire?
504 2011-06-06 03:19:23 <anarchyx> stash*
505 2011-06-06 03:19:55 <anarchyx> im thinking $10 million usd :)
506 2011-06-06 03:20:24 <cacheson> anarchyx: you have that many coins?
507 2011-06-06 03:20:29 <lfm> anarchyx: if your gonna hold out that long youll prolly end up with nothin
508 2011-06-06 03:20:45 <anarchyx> lfm: you dont believe in it?
509 2011-06-06 03:21:17 <lfm> classic bubble, it will pop and most likely before most of us are millionairs
510 2011-06-06 03:22:01 <anarchyx> i dont think its a bubble
511 2011-06-06 03:22:11 <anarchyx> its a viable alternative currency
512 2011-06-06 03:22:14 <lfm> hahaha, ok you just keep dreaming
513 2011-06-06 03:22:16 <anarchyx> people are buying in
514 2011-06-06 03:22:33 <cacheson> if bitcoin becomes successful as a currency, I could see $1000 per coin a couple years down the line... but that still means you need 10,000 coins for your target
515 2011-06-06 03:22:57 <lfm> just 1000 btc
516 2011-06-06 03:23:09 <cacheson> lfm: that'd be $1 million
517 2011-06-06 03:23:09 <lfm> oh 10 million ya
518 2011-06-06 03:23:11 <cacheson> heh
519 2011-06-06 03:23:45 <lfm> I am thinking anarchyx doesnt have 10,000 btc
520 2011-06-06 03:24:42 <anarchyx> lfm: have you been here a long time?
521 2011-06-06 03:24:51 <lfm> almost 1 year now
522 2011-06-06 03:24:59 <anarchyx> i hope you have 10k then :)
523 2011-06-06 03:25:19 <lfm> I dont think I would have 10,000 btc even if I never sold any
524 2011-06-06 03:25:29 <anarchyx> but i guess you will sell out before it hits 1k
525 2011-06-06 03:25:43 <anarchyx> how come? sept-dec period was golden to mine with gpu
526 2011-06-06 03:25:46 <anarchyx> very easy to get it
527 2011-06-06 03:26:00 <lfm> ya, I never had a decent gpu at the time
528 2011-06-06 03:29:52 <anarchyx> but yeah i definitely see it hitting $100 soon
529 2011-06-06 03:30:03 <anarchyx> its at the process of becoming mainstream news
530 2011-06-06 03:30:15 <anarchyx> after that who knows
531 2011-06-06 03:30:42 <lfm> thats the thing about bubbles, they almost always go up some more before they crash, but they always crash.
532 2011-06-06 03:32:16 <anarchyx> what do you think is its 'real price' then, if you say its a bubble
533 2011-06-06 03:32:39 <lfm> very hard to tell, maybe about $1
534 2011-06-06 03:32:49 <anarchyx> what do you determine it on?
535 2011-06-06 03:33:41 <lfm> hand waving, seat of the pants, gut feeling, take your pick
536 2011-06-06 03:34:38 <anarchyx> for me historically it always seemed to be (electricity+hardware investment paid off in a year) x 3
537 2011-06-06 03:35:02 <anarchyx> or something like that
538 2011-06-06 03:35:26 <anarchyx> difficulty included in that calculation
539 2011-06-06 03:35:30 <lfm> interesting, so what does that formula give you?
540 2011-06-06 03:36:03 <anarchyx> i dont know, i remember wanting to buy for 10 cents when it was 30 cents
541 2011-06-06 03:36:09 <Niedar> bitcoin value isnt related to mining at all
542 2011-06-06 03:36:11 <anarchyx> cause that was my value at the time
543 2011-06-06 03:36:37 <anarchyx> Niedar: well at one point it wont be anymore, but its definitely been influenced by it
544 2011-06-06 03:37:18 <lfm> Niedar: it kinda is since the basic supply of bitcoin comes from the miners. you're right tho in the sens that the current market seems to be driven by speculation
545 2011-06-06 03:37:59 <anarchyx> when mining becomes close to no longer being worth it, you see miners drop off, less supply, and prices go up
546 2011-06-06 03:38:06 <Niedar> Well yeah I guess supply factors into the equation and miners create more supply but the major factor is what people are willing to pay for them
547 2011-06-06 03:38:39 <Niedar> yeah but the supply only drops for a little while once the difficulty readjusts
548 2011-06-06 03:38:43 <Niedar> its back to the same supply
549 2011-06-06 03:38:55 <anarchyx> because its worth it again to mine
550 2011-06-06 03:38:58 <anarchyx> since price went up
551 2011-06-06 03:40:06 <Niedar> well whether the price goes up again, when less people are mining the difficulty will eventually drop and try and normalize the amount of bitcoins being created to 50 every 10 minutes
552 2011-06-06 03:40:42 <anarchyx> yeah but if price goes up so do the miners - why wouldnt they invest in more equipment?
553 2011-06-06 03:41:12 <Niedar> my point is that the supply should be around the same no matter what
554 2011-06-06 03:41:52 <anarchyx> ok i understand
555 2011-06-06 03:43:06 <anarchyx> either way ill let you know when i hit my 10 million, but i think artforz will be there before me ;)
556 2011-06-06 03:49:50 <jgarzik> theymos: how's blockexplorer.com holding up, under the weight of all the new traffic?  :)
557 2011-06-06 03:50:26 <theymos> It seems to be doing well. Sometimes it is a little slow, but I've seen no serious problems.
558 2011-06-06 03:53:50 <theymos> It has a computer all to itself (sitting behind me), so CPU/memory should be alright for a while. AT&T recently started bandwidth caps, though, so I might have to move it elsewhere if it starts taking up too much bandwidth.
559 2011-06-06 04:01:49 <ferrouswheel> I saw in some old logs that someone asked about starting a bitcoin client in erlang. Anybody have any updates on that? Am keen to start work on one but don't want to duplicate effort unnecessarily...
560 2011-06-06 04:03:09 <nanotube> ferrouswheel: search the forums... and the google. if it's not there... you're on your own. :)
561 2011-06-06 04:04:53 <ferrouswheel> nanotube: nothing else on google or the forum that i've seen. sometimes these things don't get broadly announced until there is something to show though ;-)
562 2011-06-06 04:05:27 <ferrouswheel> guess I'll dive in to it myself
563 2011-06-06 04:06:50 <nanotube> ferrouswheel: good luck :)
564 2011-06-06 04:48:13 <wistiu> lorgaborga
565 2011-06-06 05:42:39 <lfm> ls
566 2011-06-06 05:44:18 <blueCmd> jgarzik: is it possible to re-open a merge request for reconsideration?
567 2011-06-06 05:44:29 <blueCmd> pull request*
568 2011-06-06 05:45:02 <blueCmd> I commented on https://github.com/bitcoin/bitcoin/pull/63
569 2011-06-06 06:03:13 <gjs278> buying MTGOXUSD to PPUSD, looking for 1.00:1.02
570 2011-06-06 06:03:27 <gjs278> with PPUSD*
571 2011-06-06 06:03:50 <gjs278> lol wrong channel
572 2011-06-06 06:19:20 <Diablo-D3> heh
573 2011-06-06 06:19:22 <Diablo-D3> and now
574 2011-06-06 06:19:32 <Diablo-D3> satoshi is fictional
575 2011-06-06 06:19:37 <Diablo-D3> with one single message board post
576 2011-06-06 06:19:48 <gjs278> satoshi is just a pokemon joke
577 2011-06-06 06:19:52 <gjs278> that is ash's name
578 2011-06-06 06:19:55 <gjs278> that's it
579 2011-06-06 06:20:12 <Diablo-D3> gjs278: yeah but btc, gotta collect them all
580 2011-06-06 06:20:30 <gjs278> satoshi already has them all
581 2011-06-06 06:20:34 <gjs278> that's the goal of the project
582 2011-06-06 06:20:39 <gjs278> create cryptocurrency
583 2011-06-06 06:20:42 <gjs278> generate a bunch of coins
584 2011-06-06 06:20:45 <gjs278> sell them at $18
585 2011-06-06 06:22:22 <Diablo-D3> $18?
586 2011-06-06 06:22:24 <Diablo-D3> fuck dude
587 2011-06-06 06:22:25 <Diablo-D3> $1000
588 2011-06-06 06:23:12 <gjs278> you're right
589 2011-06-06 06:37:26 <Diablo-D3> seriously
590 2011-06-06 06:37:41 <Diablo-D3> fuck actual valuation
591 2011-06-06 06:45:05 <Clarence> has anybody valued bitcoins using actual math and stuff?
592 2011-06-06 06:47:17 <lfm> Clarence: what do you mean?
593 2011-06-06 06:47:47 <gjs278> Clarence I have valued bitcoins using stuff, but no math
594 2011-06-06 06:47:59 <Clarence> like financial valuation.. so I know if it's worth it to buy or not
595 2011-06-06 06:48:18 <io_error> Clarence: If they're below $1m then buy
596 2011-06-06 06:48:23 <lfm> Clarence: I dont know how youd do that
597 2011-06-06 06:49:11 <Clarence> is anybody here vocal about saying it's overpriced?
598 2011-06-06 06:49:40 <lfm> Clarence: I keep trying to tell people it is a bubble and is gonna crash but not many listen
599 2011-06-06 06:49:51 <Clarence> seriously?
600 2011-06-06 06:50:00 <lfm> ya
601 2011-06-06 06:50:04 <io_error> Clarence: Never invest more than you can afford to lose.
602 2011-06-06 06:50:14 <Clarence> is it not likly to reach 40 before it crashes?
603 2011-06-06 06:50:15 <gjs278> lfm what do you think the pop point is
604 2011-06-06 06:50:23 <gjs278> and how low do you think it will go in value
605 2011-06-06 06:50:33 <lfm> io_error: thats like saying never give me more that you can afford to lose! hehe
606 2011-06-06 06:50:50 <io_error> lfm: You need to stop playing so much poker, you suck at it :P
607 2011-06-06 06:51:19 <lfm> pop point? never heard that term before. I assume you think I can predict WHEN it will crash, sorry I cant
608 2011-06-06 06:51:39 <gjs278> I'm just asking for your guess
609 2011-06-06 06:51:45 <gjs278> of what value the coins will reach max
610 2011-06-06 06:51:51 <ferrouswheel> blueCmd, jgarzik: was that ever resolved? If that issue with client versioning tied to protocol version is still true, then I really have to reconsider whether it's worth trying to add diversity to the bitcoin ecosystem by starting another client.
611 2011-06-06 06:51:59 <io_error> Clarence: We're changing the world here. You are witnessing history in the making. None of us can predict whether Bitcoin will succeed or fail, though we're sure as hell working toward success.
612 2011-06-06 06:52:22 <lfm> gjs278: well I used to think it would be $1, then I thot it might be $10, now I am less certain
613 2011-06-06 06:52:31 <gjs278> lfm I was freaking out at 1.95
614 2011-06-06 06:52:38 <gjs278> thinking I had gotten deal of the century
615 2011-06-06 06:52:39 <Clarence> if, for instance, there's greater than 50% of it reaching 40, then i'll set sell at 40% and it will be EV+
616 2011-06-06 06:52:49 <io_error> I used to think it would be $100, then $1000, now I think it will exceed $100,000
617 2011-06-06 06:53:17 <Clarence> I want to hear lfm tho
618 2011-06-06 06:53:40 <lfm> well, I figure it will keep going up till it doesnt.
619 2011-06-06 06:53:59 <gjs278> I think 35
620 2011-06-06 06:54:00 <io_error> Clarence: I'll happily tell you that there are a few ways Bitcoin can fail. Some are technical, some are political.
621 2011-06-06 06:54:07 <gjs278> thats the most I can ever see a coin being in the next year
622 2011-06-06 06:54:23 <io_error> gjs278: Most people didn't think we'd see $20 by the end of THIS year
623 2011-06-06 06:54:28 <gjs278> well
624 2011-06-06 06:54:38 <Clarence> io-error people are only buying it to sell in the future.. not as currency
625 2011-06-06 06:54:44 <gjs278> yes
626 2011-06-06 06:54:45 <gjs278> that
627 2011-06-06 06:54:45 <lfm> gjs278: wow, thats getting warm now then
628 2011-06-06 06:54:57 <gjs278> lfm my whole thing is that everyone is just holding onto their coins
629 2011-06-06 06:55:05 <Hadaka> hello - I've got a bunch of technical questions about bitcoin - I'll start with the first: are transactions with nSequence < MAX_INT still supported?
630 2011-06-06 06:55:05 <io_error> Clarence: I dunno, Silk Road is doing a pretty brisk business :)
631 2011-06-06 06:55:06 <gjs278> and refusing to sell unless they make money off of it above exchange
632 2011-06-06 06:55:16 <gjs278> and that's going to dry up soon
633 2011-06-06 06:55:23 <Clarence> it's being debased at $140,000 a day at these prices
634 2011-06-06 06:55:25 <gjs278> I am purchasing something today with straight bitcoins
635 2011-06-06 06:55:28 <gjs278> I am doing my part
636 2011-06-06 06:55:32 <gjs278> to keep this economy moving
637 2011-06-06 06:55:53 <gjs278> will that person cash out the bitcoins the second I send them? probably
638 2011-06-06 06:56:11 <io_error> gjs278: And whoever gets them will just go to SIlk Road :)
639 2011-06-06 06:56:23 <gjs278> he'll be getting high off of freedom
640 2011-06-06 06:56:41 <gjs278> I feel about bitcoins right now like hank hill feels about propane
641 2011-06-06 06:56:43 <Hadaka> what about nLockTime? do the current clients support it?
642 2011-06-06 06:57:16 <Clarence> after it peaks it will have to compete on it's own merit as a currency otherwise it's headed to 0
643 2011-06-06 06:57:48 <io_error> Clarence: We know that too :)
644 2011-06-06 06:58:06 <lfm> gjs278: mining cashout actually
645 2011-06-06 06:58:32 <gjs278> I dumped mine at $13
646 2011-06-06 06:58:36 <gjs278> no regrets
647 2011-06-06 06:58:52 <gjs278> there was a kid poking the bubble with a needle he just got lucky
648 2011-06-06 06:58:58 <lfm> gjs278: I still have some I guess I take a bit further
649 2011-06-06 06:59:32 <Hadaka> also, is there a reason why the signed transaction does not include the sum of the incoming transactions?
650 2011-06-06 06:59:55 <lfm> Hadaka: maybe due to fees
651 2011-06-06 07:00:28 <io_error> If the outputs are less than the inputs, the remainder is the fee
652 2011-06-06 07:00:45 <Hadaka> lfm: yeah, I get the fact that fees are calculated as incoming minus outgoing
653 2011-06-06 07:01:12 <gjs278> ;;bc,stats
654 2011-06-06 07:01:16 <gribble> Current Blocks: 128978 | Current Difficulty: 434882.7217497 | Next Difficulty At Block: 129023 | Next Difficulty In: 45 blocks | Next Difficulty In About: 5 hours, 6 minutes, and 45 seconds | Next Difficulty Estimate: 562180.61168809
655 2011-06-06 07:02:03 <spq_> hey there, i have a question about bitcoin - not really dev specific - are older bitcoins(with a long history) less worth? (because they require much data to be transferred)
656 2011-06-06 07:02:05 <Hadaka> lfm: but that's just the thing - if I'm signing a transaction id, and can't be *100%* sure what it is - I might accidentally send large sums of money as fees without meaning it
657 2011-06-06 07:02:28 <Clarence> gjs278.. are you going to hold any btc at all?
658 2011-06-06 07:02:35 <lfm> Hadaka: why arnt you certain?
659 2011-06-06 07:02:38 <gjs278> I have 20 right now that I'm about to trade with
660 2011-06-06 07:02:46 <magnetron> spq_: no.
661 2011-06-06 07:02:53 <io_error> spq_: Nope, the original 50 bitcoins is worth the same as a new 50 bitcoins
662 2011-06-06 07:03:00 <Hadaka> lfm: I'm thinking about use cases where the client doesn't have the full block history available to confirm every signature etc.
663 2011-06-06 07:03:51 <spq_> wont you have to transfer the whole history of all bitcoin pieces you combine to one bitcoin?
664 2011-06-06 07:04:41 <Hadaka> lfm: well, actually I'm thinking more about the use case where the software that does signing isn't really connected to any part of the bitcoin network
665 2011-06-06 07:05:01 <spq_> (in the case where you have some(lets say 100 - 0.1 each) small bitcoin fragments which are together 1btc - and now you send them to anyone - what do you have to transfer?
666 2011-06-06 07:05:04 <lfm> Hadaka: ok well I dont know how youd do that then
667 2011-06-06 07:05:24 <io_error> spq_: You would have to transmit all of the 0.1 btc pieces you want to use
668 2011-06-06 07:05:52 <Hadaka> well, my original question stands - was there a specific reason why the signed transaction doesn't explicitly list the sums of the source transactions - or was it just a quirk of implementation?
669 2011-06-06 07:05:56 <lfm> Hadaka: you should be able to request txns by their hash from a full node I think
670 2011-06-06 07:06:01 <io_error> spq_: It's also unwise to get lots of small payments if you can avoid it, since that would then become a large transaction and have fees applied
671 2011-06-06 07:06:22 <io_error> Hadaka: To conserve space, probably. They can always be looked up.
672 2011-06-06 07:06:57 <spq_> yea - seen that, received some small payments from a bitcoin pool - had to use an older btc software version to transfer them without fees
673 2011-06-06 07:07:00 <Hadaka> lfm: I still need some way to make sure the info the node is giving me is correct - which is hard
674 2011-06-06 07:07:27 <io_error> spq_: Right, it's cheaper to spend 10 1BTC coins than to spend 100 0.1BTC coins since the latter would be a much larger (in size) transaction
675 2011-06-06 07:07:42 <spq_> but thats exactly the point it gets unattractive to process those complexer bitcoins
676 2011-06-06 07:07:44 <theymos> You always need to look up the prev_out for verification, so there's no point in listing the value.
677 2011-06-06 07:07:48 <lfm> Hadaka: yup itd be hard. I think you need to retreive full copies of the input txns
678 2011-06-06 07:08:02 <io_error> spq_: That's why they require larger fees
679 2011-06-06 07:08:12 <magnetron> spq_: you can join several small inputs together and they're suddenly a large chunk again
680 2011-06-06 07:08:39 <Hadaka> io_error: I guess the size argument could've been the definitive one...
681 2011-06-06 07:08:49 <magnetron> spq_: yes??
682 2011-06-06 07:08:53 <magnetron> yes.
683 2011-06-06 07:08:55 <lfm> io_error: you should be able to combine a few at a time in a series of steps and still avoid fees
684 2011-06-06 07:08:58 <magnetron> fucking keyboards
685 2011-06-06 07:09:33 <io_error> lfm: Yes, you could, if you were careful. And willing to wait a day or two for the inputs to mature
686 2011-06-06 07:09:58 <lfm> ya, if you're realy really cheap! grin
687 2011-06-06 07:10:17 <magnetron> io_error: wait "a day or two" why would that long time be needed
688 2011-06-06 07:10:25 <spq_> why doesnt the btc software first combine the btc's and then send them when they are small again?
689 2011-06-06 07:10:33 <io_error> magnetron: Older inputs have a higher priority depending on how long they've aged
690 2011-06-06 07:10:37 <magnetron> spq_: combine == sending
691 2011-06-06 07:10:40 <spq_> okay
692 2011-06-06 07:11:15 <lfm> spq_: huh? every step needs to be in the block chain that is distributed to all the nodes
693 2011-06-06 07:12:12 <manveru> what do you mean with "transaction size" ?
694 2011-06-06 07:12:23 <manveru> any place i can read about that?
695 2011-06-06 07:12:30 <Hadaka> bummer, 8 bytes per input more in a transaction and things could've been a lot simpler - and I guess there's no backward compatible way of adding those...
696 2011-06-06 07:12:33 <io_error> manveru: The number of bytes the transaction data uses
697 2011-06-06 07:12:46 <spq_> okay, the receiver now got 1btc in much pieces - when he sends this btc - it is a small transaction again?
698 2011-06-06 07:13:04 <theymos> Hadaka: What are you trying to do?
699 2011-06-06 07:13:17 <magnetron> spq_: please rephrase the question
700 2011-06-06 07:13:20 <io_error> spq_: Right. When you send a bunch of bitcoins to somebody, the processor (miner) destroys all the coins and makes new ones with the combined values
701 2011-06-06 07:13:21 <lfm> manveru: its kinda hard to see from the user level. It is the number of bytes needed to perform the transaction requested. it depends mainly how many input transactions there are for it
702 2011-06-06 07:13:31 <spq_> ah okay
703 2011-06-06 07:13:59 <manveru> hm
704 2011-06-06 07:14:08 <Hadaka> theymos: I'd like to have safe "offline" signing for a transaction - that the entire transaction could be viewed and verified in simple format and then the user can choose to accept it or not
705 2011-06-06 07:14:12 <io_error> spq_: So for example if I have a 0.57BTC coin and a 0.43BTC coin, and I want to send somebody 0.75BTC, my two coins get destroyed, and a new 0.75BTC coin goes to my recipient, and a new 0.25BTC coin comes back to me
706 2011-06-06 07:14:30 <manveru> so if someone sends me 100 btc in a transaction, i can spend that without fees, but if if get 100x1 btc, i have to pay?
707 2011-06-06 07:14:51 <lfm> io_error: yup the new 0.25 is your "change"
708 2011-06-06 07:15:02 <io_error> manveru: If you spend 100 inputs all at once, then it will be a giant transaction and you'll have to pay some fees on it
709 2011-06-06 07:15:08 <magnetron> Hadaka: if that's what you want, it's not bitcoins anymore
710 2011-06-06 07:15:17 <spq_> how much inputs(btc fragments) am i allowed to send without paying a fee?
711 2011-06-06 07:15:28 <manveru> hum
712 2011-06-06 07:15:44 <io_error> spq_: At a guess I'd say 4 or 5, though I don't remember exactly right now
713 2011-06-06 07:15:48 <Hadaka> theymos: verifying destination addresses is always a problem, but it's a simple and a known one - but verifying that the source coins are actually of the size I think they are would require having authentic transactino history...
714 2011-06-06 07:15:56 <manveru> so, first i should combine those transactions by doing a loop that sends them to myself to combine them without fees?
715 2011-06-06 07:16:03 <Hadaka> magnetron: why not? just the signing process is offline, everything else is as is
716 2011-06-06 07:16:38 <lfm> manveru: ya, its not very intuitive for the user but thats what they are doing currently. it is a "policy" that is subject to change from version to version and so it will probably change again in the future
717 2011-06-06 07:16:54 <theymos> Hadaka: The signer can just be given the previous transaction. It's not too hard. You don't have to do any verification other than the hash, which is easy.
718 2011-06-06 07:16:55 <magnetron> Hadaka: bitcoins only exist in the distributed block chain, and if you don't have access to it (you're "offline") you don't know anything about the bitcoins at all.
719 2011-06-06 07:17:23 <Hadaka> theymos: but how does the signer know the previous transaction is valid and accepted? anybody can create a transaction and hash it?
720 2011-06-06 07:17:29 <io_error> manveru: Yes, you can do that. Or you can just pay the fees. :)
721 2011-06-06 07:17:32 <spq_> ok that means i can combine the btc's in my wallet 4 at a time(if that number is right) and by that make the btcs bigger again
722 2011-06-06 07:17:52 <lfm> magnetron: well you maybe have an old bl9ock chain up to the point you were last online
723 2011-06-06 07:17:58 <manveru> wouldn't it be better if i could set up my own miner that only handles my own transactions for free?
724 2011-06-06 07:17:59 <Hadaka> magnetron: the point isn't that nobody would have access to the distributed block chain - just that the device that's doing the signing does not, and can't trust anyone else
725 2011-06-06 07:18:11 <io_error> manveru: You could do that too :)
726 2011-06-06 07:18:16 <magnetron> lfm: yes, and that is still not useful for saying stuff about the current state
727 2011-06-06 07:18:22 <manveru> is that technically possible?
728 2011-06-06 07:18:28 <lfm> manveru: you could but it might take a long time for you to find a block
729 2011-06-06 07:19:21 <io_error> I don't really have much problem with the fees, it's a lot less than PayPal!
730 2011-06-06 07:19:30 <lfm> magnetron: i know I know, it is not nice and it is activley being debated. just we are kinda stuck with it for now
731 2011-06-06 07:19:39 <manveru> io_error: for now
732 2011-06-06 07:19:41 <magnetron> manveru: smart mining pools always include their own transactions in the blocks they mine
733 2011-06-06 07:19:51 <manveru> when i started bitcoin people said that transfers are free :P
734 2011-06-06 07:20:00 <io_error> manveru: The fees also will be reduced further in the next version of bitcoin
735 2011-06-06 07:20:28 <lfm> there should be a new version within a day or two
736 2011-06-06 07:20:33 <theymos> Hadaka: The hash can only represent one piece of data, so you'll know the output values. It doesn't matter whether these are accepted or not. The values are guaranteed to be accurate.
737 2011-06-06 07:20:41 <io_error> I think they are just waiting on the major pools to update
738 2011-06-06 07:21:54 <Hadaka> theymos: but if the hash isn't signed, how do I know it's a hash for a real transaction instead of a fake one?
739 2011-06-06 07:22:39 <theymos> Hadaka: Why do you care? You wanted output values: these are guaranteed to be the correct values for the inputs you're signing.
740 2011-06-06 07:22:57 <lfm> Hadaka: if it is burried a ways in the block chain you can start to have confidence in it
741 2011-06-06 07:23:23 <theymos> It doesn't matter whether it's in a block, or even if it's a valid script. You know the values.
742 2011-06-06 07:23:33 <lfm> Hadaka: the depth level you want to trust is up to you
743 2011-06-06 07:23:50 <magnetron> Feature request: randomized inbound ports
744 2011-06-06 07:24:10 <magnetron> to prevent silly bitcoin-style blocked ports
745 2011-06-06 07:24:22 <magnetron> i mean bitttorrent-style
746 2011-06-06 07:24:27 <Hadaka> theymos: okay - case in point - my signing software gets an input transaction to be signed - that references my own coins - and outputs 1 BTC to some public key - if I sign this, and the coin that is in the input is of the size of 1 BTC, everything is fine - but if it is the coin of my life savings, 1000 BTC - I am accidentally signing 999 BTC as transaction fees
747 2011-06-06 07:24:42 <Hadaka> lfm: yeah, understood - but that requires the block chain to verify
748 2011-06-06 07:24:59 <theymos> Hadaka: Right. But you're sent the previous transactions for the inputs, so you know the input values.
749 2011-06-06 07:25:28 <lfm> Hadaka: ya, you need to know the values of the inputs of course, so you have to look up those transactions
750 2011-06-06 07:25:36 <manveru> magnetron: second that
751 2011-06-06 07:26:12 <lfm> Hadaka: or have them recorded in a wallet file you can trust
752 2011-06-06 07:26:56 <Hadaka> theymos: but how do I know the previous transactions are real? if they are not real, they might accidentally be one of the saving transactions I have?
753 2011-06-06 07:27:19 <lfm> Hadaka: well DONT DO THAT!
754 2011-06-06 07:27:26 <io_error> Hadaka: You send the balance back to a new address of your own
755 2011-06-06 07:27:50 <theymos> Hadaka: Why do you care whether it's real? If not, you'll just sign an invalid transaction.
756 2011-06-06 07:28:54 <lfm> Hadaka: if you dont have the whole block chain to examine you will HAVE TO TRUST YOUR SERVER
757 2011-06-06 07:30:25 <Hadaka> io_error: but how do I know how much balance to send back to a new address of my own, if I can't be sure of the source transactions
758 2011-06-06 07:30:57 <Hadaka> theymos: okay, I don't mean fake as in completely made up, I mean fake as in somebody substitutes some other valid transaction of mine which has a different size
759 2011-06-06 07:31:44 <lfm> Hadaka: well of course you have to be sure. you have to have a trustworth way to confirm them. either trustworth data in your wallet or a trustworthy server you can query
760 2011-06-06 07:31:54 <theymos> You KNOW the size from the transactions they give you. They can't fake it.
761 2011-06-06 07:32:01 <Hadaka> lfm: yeah, I get your point - but this problem in trust could be sort of avoided if the sums of the source transactions were recorded
762 2011-06-06 07:32:35 <lfm> Hadaka: ok so record them for yourself in your wallet file
763 2011-06-06 07:33:25 <Hadaka> yeah, in the current system an offline signer can't really work unless it has a trusted list of unspent transactions that it can check to get the sums...
764 2011-06-06 07:33:38 <lfm> exactly
765 2011-06-06 07:33:46 <theymos> They're giving you old transactions for inputs: "tx A, output: 250 BTC", "tx B, output: 100 BTC". Plus a new transaction for signing: "input A & B". Just sum the output values from the old transactions provided.
766 2011-06-06 07:34:39 <theymos> If they fail to give you a required output, it's obvious and invalid. If the inputs are made up, the hash is invalid (which you'll verify) or the transaction is invalid.
767 2011-06-06 07:34:40 <io_error> Hadaka: Are you saying you want something that will sign transactions that has absolutely no idea how much money is available to spend and has never seen the transactions?
768 2011-06-06 07:35:22 <Hadaka> theymos: hmmh... yeah, actually you are correct... hashes are preimage resistant after all...
769 2011-06-06 07:36:28 <Hadaka> theymos: thanks for persisting with me :)
770 2011-06-06 07:36:43 <theymos> np
771 2011-06-06 07:38:17 <Hadaka> io_error: more or less yes - the less code involved with signing, the better
772 2011-06-06 07:38:33 <io_error> Hadaka: What in the world are you trying to build?
773 2011-06-06 07:39:12 <lfm> sounds like some phone app or something eh
774 2011-06-06 07:40:21 <Hadaka> io_error: I consider keeping unencrypted (or unencrypted to root access on a machine) private keys on a user machine pretty insane - I mean, I would *never* do that for a GPG signing key, and bitcoin wallets are even more important
775 2011-06-06 07:40:43 <Hadaka> io_error: passphrase encryption helps, but ideally the private key should not even be present on the user machine
776 2011-06-06 07:41:21 <Hadaka> io_error: and the only reason the private key is ever needed is to sign (authorize) new money transfers
777 2011-06-06 07:41:34 <lfm> huh? you mean it should be in a dongle or something? you can do that too if you want pretty easy
778 2011-06-06 07:42:27 <Hadaka> io_error: so the actual signing operation should be isolated as completely from other parts of the system to minimize exploit potential - which would pretty much mean giving in an unsigned transaction, and outputting a signed transaction - and hopefully requiring no long-term storage of blocks, transactions, or anything else
779 2011-06-06 07:43:14 <lfm> Hadaka: oh you want bank vault level security? thats a whole different application
780 2011-06-06 07:44:25 <Hadaka> lfm: is bitcoin security lacking for that kind of security? I don't mean the wallet implementations, I mean all the other stuff, generating blocks etc.
781 2011-06-06 07:44:37 <theymos> Doing the signing in a smart card is a good idea. This would be much easier for most people to understand, and it's more secure. "Your money == this card."
782 2011-06-06 07:45:13 <Hadaka> signing in a smart card is problematic because a smart card does not have a display, so you need to trust the machine you stick the smart card in to
783 2011-06-06 07:45:13 <lfm> Hadaka: well obviously the current clients dont spearate things out like that. If you want it you can implement it for your self tho
784 2011-06-06 07:45:36 <Hadaka> lfm: well, that's what I'm investigating, hence my questions
785 2011-06-06 07:46:49 <lfm> Hadaka: ok so yes, to sign a txn you would want complete copies of all the input txns used.
786 2011-06-06 07:47:21 <Hadaka> but yeah, I got my answer on that - given in a list of "in" transactions (the full transaction objects) and the transaction to be signed - the signature can be created safely creating either an invalid transaction or a valid transaction that is exactly like expected
787 2011-06-06 07:47:30 <Hadaka> lfm: right
788 2011-06-06 07:47:40 <lfm> cuz the txn ref is a hash of the input txn (plus the index of the output number)
789 2011-06-06 07:47:56 <Hadaka> and the important thing to verify is to hash the input transactions and see if the hashes match the inputs in the transaction to be signed
790 2011-06-06 07:48:22 <lfm> yup and at the same time then you can check the input values
791 2011-06-06 07:50:07 <Hadaka> okay so back to my other questions - is lock_time respected by bitcoin clients these days? what about sequence?
792 2011-06-06 07:50:24 <lfm> Id say avoid those
793 2011-06-06 07:51:04 <Hadaka> and are the two common scripts generated by bitcoin clients nowadays the only accepted ones?
794 2011-06-06 07:51:05 <lfm> implementation could be spotty. they are really kinda just reserved for future use
795 2011-06-06 07:51:06 <theymos> lockTime is respected. sequence is allowed, but it currently doesn't do anything.
796 2011-06-06 07:51:30 <theymos> Other scripts are allowed in blocks, but are not included by stock Bitcoin miners.
797 2011-06-06 07:51:54 <Hadaka> so, for example, allt he stuff here https://en.bitcoin.it/wiki/Contracts doesn't really exist in bitcoin, but is just something that could someday be done?
798 2011-06-06 07:52:04 <theymos> It can be done now.
799 2011-06-06 07:52:19 <Hadaka> but if the stock miners will not include those transactions, how would they ever be valid?
800 2011-06-06 07:52:27 <lfm> well ya safest to just avoid it
801 2011-06-06 07:52:36 <gjs278> right now, if you send a coin to someone
802 2011-06-06 07:52:40 <Hadaka> or are there enough miners on the network that allow such scripts that the transaction could be valid, in say, a day?
803 2011-06-06 07:52:42 <gjs278> and they don't want to live up to their end of the bargain
804 2011-06-06 07:52:44 <gjs278> you're basically screwed
805 2011-06-06 07:52:57 <lfm> Hadaka: the only way to use em is if you can mine them yourself with special miners
806 2011-06-06 07:53:05 <theymos> Hadaka: Eligius does, so it should take only a few hours.
807 2011-06-06 07:53:27 <lfm> easy if you have your own tame pool! hehe
808 2011-06-06 07:53:33 <theymos> The host computer for the card thing will be able to cancel unconfirmed transactions by creating conflicting transactions.
809 2011-06-06 07:54:26 <lfm> theymos: the host might not have the private keys tho
810 2011-06-06 07:54:30 <Hadaka> hmmh, I wonder how much does it cost to mine a block in Amazon EC2 these days...
811 2011-06-06 07:54:58 <lfm> Hadaka: amazon charges more than you can make
812 2011-06-06 07:55:28 <theymos> lfm: For the next transaction, it will just ask the card to spend inputs that have already been spent (all in one, even). Only a minor annoyace, but a possible attack.
813 2011-06-06 07:55:36 <Hadaka> lfm: I know that, I was just wondering if the cost was too high even for testing custom scripts...
814 2011-06-06 07:55:50 <theymos> Non-standard transactions are allowed on testnet.
815 2011-06-06 07:55:54 <gjs278> they charge more than you can make, but if you did it awhile ago, you could have genned a bunch of coins and then sold them later at 18x the value
816 2011-06-06 07:56:04 <gjs278> thats the only scenario is makes sense
817 2011-06-06 07:56:07 <gjs278> if you can see the future
818 2011-06-06 07:56:08 <Hadaka> theymos: ah
819 2011-06-06 07:56:09 <gjs278> then it was the way to go
820 2011-06-06 07:57:06 <eps1> ;;bc,stats
821 2011-06-06 07:57:08 <gribble> Current Blocks: 128991 | Current Difficulty: 434882.7217497 | Next Difficulty At Block: 129023 | Next Difficulty In: 32 blocks | Next Difficulty In About: 3 hours, 36 minutes, and 0 seconds | Next Difficulty Estimate: 563493.28036112
822 2011-06-06 08:03:11 <Hadaka> hmh, if my calculations aren't totally off the mark, I'd say around $5000 to get a block off of Amazon EC2
823 2011-06-06 08:04:22 <MasterChief> lolwut
824 2011-06-06 08:04:35 <theymos> vs less than a cent to pay for Eligius to include a non-standard transaction.
825 2011-06-06 08:06:38 <Hadaka> difficulty * 2^32 / hashrate / 1 hour * price of 1 hour = (((434882.7217497*(2^32))/(205.6*1000*1000))/60/60)*2.1 = ~5300
826 2011-06-06 08:07:37 <MasterChief> ec2 runs on tesla cards right
827 2011-06-06 08:08:10 <Hadaka> MasterChief: so the pages say
828 2011-06-06 08:09:09 <MasterChief> would it be economical to use ec2 to mine if they used radeons?
829 2011-06-06 08:10:20 <blueCmd> ferrouswheel: no, it was never resolved.
830 2011-06-06 08:13:08 <blueCmd> ferrouswheel: please comment on the pull request to make this happen, we need all the support we can get I think.
831 2011-06-06 08:13:39 <enki> MasterChief: start a EBMC instead - the elastic bitcoin mining cloud
832 2011-06-06 08:13:56 <enki> ppl can buy your mining machines ;)
833 2011-06-06 08:14:08 <enki> or do mining as a service
834 2011-06-06 08:14:33 <lfm> enki: that makes no sense really, just mine for yourself
835 2011-06-06 08:14:36 <io_error> MasterChief: If they used AMD GPUs, we'd all be mining on Amazon EC2
836 2011-06-06 08:14:46 <MasterChief> hmm
837 2011-06-06 08:15:04 <io_error> Well, maybe not.
838 2011-06-06 08:15:06 <MasterChief> io_error but wouldent they make more money mining for themselvs then
839 2011-06-06 08:15:27 <Hadaka> MasterChief: theoretically at least - AMD can be 5 times more effective than nvidia, and 50 BTC will probably cost $1000 in a bit
840 2011-06-06 08:15:53 <lfm> MasterChief: they would need to increase their rates till it was uneconomical
841 2011-06-06 08:16:31 <io_error> MasterChief: OK, one of their compute units costs $50/day to run, two 5850s gets me about 1.5BTC at current difficulty, and the exchange rate is... Nope, even if they used AMD GPUs it still wouldn't work
842 2011-06-06 08:16:36 <Hadaka> erm - would they care about the price of bitcoin, really? it may tank the next day - I don't think it would affect their rates at all
843 2011-06-06 08:17:11 <lfm> miners would buy up all their capacity
844 2011-06-06 08:17:43 <io_error> Now if it were two 6990s, and you only did spot pricing, then it could POSSIBLY work