1 2011-12-27 00:06:33 <roconnor> um, can someone double check with me that post-fix ++ returns the unincremented value
  2 2011-12-27 00:07:03 <roconnor> and thus the current code doesn't stop arbitrarly deep nestings of OP_EVAL?
  3 2011-12-27 00:07:35 <roconnor> though maybe it still stops infinite loops
  4 2011-12-27 00:07:53 <roconnor> BBL
  5 2011-12-27 00:07:54 <luke-jr> roconnor: yep
  6 2011-12-27 00:08:16 <luke-jr> I didn't even think of that one >_<
  7 2011-12-27 00:10:55 <cjdelisle> in most things, security issues aren't "real" until they are proven -- by crashing a significant number of nodes
  8 2011-12-27 00:11:43 <cjdelisle> sometimes a whole network is brought to the ground and the serucity issue still isn't acknoleged
  9 2011-12-27 00:11:51 <cjdelisle> *cough* solidcoin
 10 2011-12-27 00:12:08 <gmaxwell> "it's a feature, not a bug"
 11 2011-12-27 00:12:38 <cjdelisle> hehe the solidcoin network suicide feature
 12 2011-12-27 00:57:02 <roconnor> luke-jr: I'm pretty sure it doesn't even stop infinite loops
 13 2011-12-27 00:57:18 <roconnor> OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL
 14 2011-12-27 00:57:34 <roconnor> I conjecture that runs in an infinite loop with the current code
 15 2011-12-27 00:57:43 <roconnor> or at least until the call stack explodes
 16 2011-12-27 00:59:23 <roconnor> OP_EVAL needs a proper spec and the whole scripting systems needs a spec that bounds the memory and time use before any changes are made
 17 2011-12-27 00:59:25 <roconnor> IMHO
 18 2011-12-27 01:02:49 <roconnor> luke-jr: it only took me 70 minutes to find a bug....
 19 2011-12-27 01:02:58 <roconnor> well, I guess I should prove it is a bug
 20 2011-12-27 01:26:49 <roconnor> pfft, the OP_EVAL code is already in the HEAD
 21 2011-12-27 01:27:51 <gmaxwell> roconnor: yes, but there hasn't been a release with it yet.
 22 2011-12-27 01:28:02 <roconnor> I'll post an issue
 23 2011-12-27 01:28:04 <cjdelisle> wait till there's couple hundred nodes running it -- crash them -- then make your case for a slower dev cycle
 24 2011-12-27 01:28:16 <roconnor> cjdelisle: I'm tempted by this
 25 2011-12-27 01:28:37 <gmaxwell> No need for the adversarial approach.
 26 2011-12-27 01:28:53 <roconnor> I'll try the nice approach first
 27 2011-12-27 01:29:06 <cjdelisle> it's not like you'll be crashing people who use it for really important stuff or people who don't understand the code, most will be devs and beta testers if you do it early
 28 2011-12-27 01:30:42 <cjdelisle> and I'm sure I will be greeted with the very same wakeup call in my own project..
 29 2011-12-27 01:32:05 <rjk2> hehe
 30 2011-12-27 01:33:07 <luke-jr> roconnor: IMO, the entire scripting system should be revamped, and only the new form allowed inside OP_EVAL
 31 2011-12-27 01:33:24 <roconnor> luke-jr: I wouldn't disagree with that
 32 2011-12-27 01:33:28 <luke-jr> cjdelisle: no, the dev cycle isn't the problem
 33 2011-12-27 01:33:35 <luke-jr> cjdelisle: the review cycle for *protocol* changes is
 34 2011-12-27 01:33:50 <luke-jr> the dev cycle is already far too slow
 35 2011-12-27 01:34:36 <rjk2> same problem as most projects - lack of many dedicated testers :(
 36 2011-12-27 01:34:42 <cjdelisle> indeed, I retract my hastily chosen words
 37 2011-12-27 01:35:12 <luke-jr> Bitcoin.org needs to be revamped to present multiple versions of multiple clients
 38 2011-12-27 01:35:33 <roconnor> rjk2: testing only shows the presence of bugs, not their absance.
 39 2011-12-27 01:35:36 <gmaxwell> presenting _more_ clients doesn't help this at all.
 40 2011-12-27 01:35:41 <gmaxwell> In fact, it makes it worse.
 41 2011-12-27 01:35:59 <luke-jr> and categorized under "stable for long-term production use", "testing for regular users", and "bleeding edge with new features"
 42 2011-12-27 01:36:11 <gmaxwell> Because if _any_ widely used client has a difference in the validation logic you can use it to make nasty forks which can be worse than the mere misbehavior.
 43 2011-12-27 01:37:10 <cjdelisle> more clients exposes bugs
 44 2011-12-27 01:37:26 <cjdelisle> but if you really don't like bugs, perhaps you rather they not be exposed ;)
 45 2011-12-27 01:39:01 <luke-jr> long-term production should be rolling out 0.4.x now IMO
 46 2011-12-27 01:39:32 <gmaxwell> cjdelisle: There are multiple kinds of bugs.
 47 2011-12-27 01:40:03 <gmaxwell> cjdelisle: In particular, there are places in bitcoin (block validation) where any _difference_ in behavior can be fatal, even if any of the different ways would be perfectly fine on their own.
 48 2011-12-27 01:41:17 <cjdelisle> /nod
 49 2011-12-27 01:43:48 <roconnor> https://github.com/bitcoin/bitcoin/issues/729
 50 2011-12-27 01:43:51 <roconnor> complete with rant
 51 2011-12-27 01:47:10 <luke-jr> roconnor: that's not the mailing list
 52 2011-12-27 01:47:30 <roconnor> I'm not getting involved in any mailing list
 53 2011-12-27 01:47:35 <sipa> still it will be seen
 54 2011-12-27 01:48:01 <roconnor> I don't really want to be involved in the development of the bitcoin client
 55 2011-12-27 01:48:12 <luke-jr> roconnor: the mailing list is not for any specific client.
 56 2011-12-27 01:51:22 <roconnor> luke-jr: I'll think about it
 57 2011-12-27 02:21:05 <roconnor> Ideally you'd be able to determine (a resonable bound on) the runtime of a script before evaluating it;  OP_EVAL pretty much destroys this property.
 58 2011-12-27 02:22:20 <gmaxwell> roconnor: it doesn't if its invocation is limited.
 59 2011-12-27 02:22:41 <gmaxwell> it's the same thing as bounding a runtime on a language with finite recursion. (er because thats what it is)
 60 2011-12-27 02:23:34 <roconnor> yes, but you won't get a resonable estimate of, say, the number of CHECKSIGS because the values passed to OP_EVAL can be computed by arithmetic operations.
 61 2011-12-27 02:23:47 <roconnor> as it stands you can simply count them right now
 62 2011-12-27 02:24:16 <roconnor> and even with OP_IF you can get a resonable count of the maximum number of CHECKSIGS by enumerating paths.
 63 2011-12-27 02:24:20 <roconnor> (If you wanted)
 64 2011-12-27 02:24:28 <gmaxwell> oh. bleh. well you can still terminate if it gets too big.
 65 2011-12-27 02:25:30 <roconnor> I'm sure miners would appreciate knowing before execution
 66 2011-12-27 02:25:36 <roconnor> we'll I guess I'm not sure
 67 2011-12-27 02:28:07 <gmaxwell> I agree that its a good goal, but .. I'm not sure it matters. It does matter that complexity is roughly proportional to size.. but I think you can ignore checksig for that purpose.
 68 2011-12-27 03:05:16 <CIA-100> bitcoin: Con Kolivas * r9f41f2f34184 cgminer/main.c: Try to align device outputs in curses output. http://luke.dashjr.org/programs/bitcoin/w/cpuminer/cgminer.git/commitdiff/9f41f2f34184afce1ba8c9616a9d6aeb45da41fa
 69 2011-12-27 03:35:10 <CIA-100> bitcoin: Con Kolivas * r17ea91aef598 cgminer/README: Update README. http://tinyurl.com/csr8zay
 70 2011-12-27 04:35:10 <CIA-100> bitcoin: Con Kolivas * r1d0730a85963 cgminer/NEWS: Update NEWS. http://tinyurl.com/bvwc6ok
 71 2011-12-27 04:35:12 <CIA-100> bitcoin: Con Kolivas * r4f879b42864c cgminer/configure.ac: Bump version to 2.1.0. http://tinyurl.com/bpp7slj
 72 2011-12-27 05:34:14 <roconnor> Ugh, even if OP_VERIF or OP_VERNOTIF occurs in an unexecuted IF_ELSE_END branch the transaction is invalid.
 73 2011-12-27 05:34:49 <roconnor> but if other reserved words are occur in an unexecuted IF_ELSE_END branch then the transaction is not invalidated
 74 2011-12-27 05:44:29 <nanotube> it appears that bitcoin-qt client shows the datetime of the transaction as the time it was first seen by the client, rather than the timestamp in the actual transaction
 75 2011-12-27 05:45:27 <roconnor> OP_IFDUP is bizarre
 76 2011-12-27 05:45:28 <nanotube> (i just updated my blockchain from the past three days or so... and have a couple transactions with 400-some and 500-some confirmations, dating as of an hour ago (apparently when client first saw them)
 77 2011-12-27 05:45:35 <nanotube> can anyone confirm or deny this behavior?
 78 2011-12-27 05:46:07 <gmaxwell> nanotube: thats the behavior as I understand it, yes.
 79 2011-12-27 05:46:28 <nanotube> gmaxwell: iirc, the old wx client used to show actual tx datetime?
 80 2011-12-27 05:46:40 <nanotube> at any rate, this seems to me undesirable behavior...
 81 2011-12-27 05:47:18 <gmaxwell> nanotube: it's the only time you can really trust. ... I don't know what the old wx behavior was. You're not the first to comment on this, but I think you're the first who I've seen say it changed.
 82 2011-12-27 05:47:28 <nanotube> client should, imo, either show timestamp on the tx, or show timestamp when it first saw it AND timestamp of the tx.
 83 2011-12-27 05:47:44 <BlueMatt> nanotube: tell wumpus to fix it :)
 84 2011-12-27 05:48:03 <nanotube> gmaxwell: well, i can't be sure what it was in the wx client at this moment, just 'iirc' :)
 85 2011-12-27 05:48:18 <nanotube> wumpus: ^ fix it :)
 86 2011-12-27 05:48:24 <nanotube> BlueMatt: done :D
 87 2011-12-27 05:49:02 <nanotube> gmaxwell: it's fine for unconfirmed tx flying about... but when catching up on the blockchain... it is a little useless to show 'time first seen' on transactions.
 88 2011-12-27 05:49:07 <BlueMatt> (its nice that wumpus is an official developer, that way we can tell him to fix things instead of doing it ourselves :)
 89 2011-12-27 05:49:26 <nanotube> (consider, if deleting a blockchain and refetching it, all your tx will show the timestamp of "today" which is useless)
 90 2011-12-27 05:49:34 <BlueMatt> random poll: (word :) or (word :) ) or (word :))
 91 2011-12-27 05:49:47 <nanotube> BlueMatt: (word :) )
 92 2011-12-27 05:50:00 <nanotube> sometimes the latter. but never the first. :)
 93 2011-12-27 05:50:25 <gmaxwell> it's too bad that some many blocks are horribly mistimed now.
 94 2011-12-27 05:50:55 <BlueMatt> is that a mainline client or a miners with bad clocks thing?
 95 2011-12-27 05:51:07 <nanotube> BlueMatt: probably rolling ntime thing for miners
 96 2011-12-27 05:51:14 <gmaxwell> what nanotube said.
 97 2011-12-27 05:51:15 <BlueMatt> mmm
 98 2011-12-27 05:51:23 <BlueMatt> ah, that makes sense
 99 2011-12-27 05:51:24 <gmaxwell> Probably a little bit of miners with bad clocks too. Not an attack.
100 2011-12-27 05:51:47 <BlueMatt> yea, thought so but I cant say Im farmiliar with the bitcoin timing code that well...
101 2011-12-27 05:51:55 <gmaxwell> It's kinda dumb.
102 2011-12-27 05:52:09 <BlueMatt> (well I guess Im not that familiar with many specific bitcoin workings, but whatever...)
103 2011-12-27 05:52:15 <gmaxwell> You learn offsets from your neighbors which you never forget, and apply the median of those as a correction.
104 2011-12-27 05:52:25 <BlueMatt> oh, fun
105 2011-12-27 05:53:01 <gmaxwell> if your clock starts of stupid but slews correct (e.g. bitcoind and ntp starting at the same time), the correction will be screwing up your time.
106 2011-12-27 05:54:15 <BlueMatt> oh, even more fun
107 2011-12-27 05:54:43 <nanotube> gmaxwell: file a github issue :)
108 2011-12-27 05:55:34 <BlueMatt> nanotube: heh, like anyone is gonna spend the time to write a fix...
109 2011-12-27 05:56:03 <gmaxwell> well, my fix is to just use NTP locally when you know its correct and ignore network time.
110 2011-12-27 05:56:17 <gmaxwell> Some other p2p software calls NTP directly to ask it if it thinks its in sync.
111 2011-12-27 05:56:47 <BlueMatt> agreed...
112 2011-12-27 05:56:48 <gmaxwell> (e.g. gtk-gnutella does this)
113 2011-12-27 05:57:54 <gmaxwell> and high value sites should really have good ntp setups (e.g. a local gps clock $100-$200 on ebay. :) ) but ::shrugs::
114 2011-12-27 05:58:13 <gmaxwell> I think it's pretty typical that my home network is more securely configured than bit bitcoin ecommerce sites. :)
115 2011-12-27 05:58:15 <nanotube> gmaxwell: why not just make peer-offsets forgettable? (i.e., refresh at regular intervals?)
116 2011-12-27 05:58:54 <nanotube> that may be a less draconian change
117 2011-12-27 05:59:27 <luke-jr> nanotube: transactions don't have timestamps
118 2011-12-27 05:59:31 <BlueMatt> luke-jr: hey, you know its true...
119 2011-12-27 05:59:42 <gmaxwell> luke-jr: but blocks do
120 2011-12-27 05:59:52 <gmaxwell> sadly they are often pretty wrong
121 2011-12-27 06:00:05 <luke-jr> BlueMatt: actually, I don't see any follow option
122 2011-12-27 06:00:13 <luke-jr> BlueMatt: nor know of any decent RSS reader :P
123 2011-12-27 06:00:20 <gmaxwell> nanotube: that would help, but might somehwhat increase the vulnerability to e.g. the time splitting attack so it should be considered carefully.
124 2011-12-27 06:00:20 <nanotube> luke-jr: well yea i mean the block that it's in. i'd rather see the timestamp of the block, than the timestamp of when i saw it, because when i saw it can be dramatically wrong, while block timestamp can be only somewhat wrong.
125 2011-12-27 06:00:43 <luke-jr> nanotube: I'd rather see the timestamp I first saw it. :P
126 2011-12-27 06:00:51 <gmaxwell> fight fight
127 2011-12-27 06:00:52 <BlueMatt> luke-jr: you get a "personal feed" which has all of your subscriptions on github
128 2011-12-27 06:01:04 <luke-jr> nanotube: actually, there's a thread on the dev forum where I posted ideal behaviour IMO
129 2011-12-27 06:01:12 <BlueMatt> its https://github.com/user.private.atom?token=unique token to make it private(ish)
130 2011-12-27 06:01:20 <nanotube> luke-jr: and when you dump the blockchain and refetch it... you'd rather see all your tx show up as being from today?
131 2011-12-27 06:01:31 <luke-jr> nanotube: no
132 2011-12-27 06:01:38 <BlueMatt> luke-jr: there has been discussion of timing upgrades over and over, but it hasnt happened (as always seems to happen in bitcoin...)
133 2011-12-27 06:01:45 <luke-jr> nanotube: AIUI, transactions involving you are saved in wallet.dat too ;p
134 2011-12-27 06:02:00 <luke-jr> BlueMatt: ?
135 2011-12-27 06:02:14 <BlueMatt> luke-jr: plenty of talk, not enough code
136 2011-12-27 06:02:45 <nanotube> luke-jr: well, wasn't sure if the timestamp is 'refreshed' when you reget the blockchain. heh.
137 2011-12-27 06:03:01 <luke-jr> nanotube: anyhow, I think my proposed solution works for everyone
138 2011-12-27 06:03:08 <BlueMatt> linky?
139 2011-12-27 06:03:10 <nanotube> luke-jr: linky?
140 2011-12-27 06:03:11 <BlueMatt> code?
141 2011-12-27 06:03:13 <nanotube> heh
142 2011-12-27 06:04:08 <luke-jr> https://bitcointalk.org/index.php?topic=54527.0
143 2011-12-27 06:10:11 <CIA-100> bitcoin: Con Kolivas * r4c1c825084c6 cgminer/README: Fix typos courtesy of Steve Brecher. http://tinyurl.com/buf3j3n
144 2011-12-27 06:10:24 <nanotube> ic, interesting. not sure i'm happy with "i send a tx, while not being up to date on the blockchain, then download some old blocks... and any tx to me in those get a timestamp that must be >= the tx i just sent" bit
145 2011-12-27 06:10:37 <nanotube> but i understand the desirability of avoiding listtransactions reshuffling....
146 2011-12-27 07:00:19 <CIA-100> bitcoin: Kano * r5033dcd355e6 cgminer/ (README main.c miner.h util.c): fix test/set of thr->pth to also work in windows http://tinyurl.com/7hoggny
147 2011-12-27 07:00:20 <CIA-100> bitcoin: Con Kolivas * rd1f896a64ae3 cgminer/ (README main.c miner.h util.c): Merge pull request #63 from kanoi/master http://tinyurl.com/7ew6sc5
148 2011-12-27 07:29:49 <wumpus> nanotube: the old wx behaviour was the same, I took that over
149 2011-12-27 07:37:35 <wumpus> could add the actual block time/date to the "transaction details" if it's not yet in there
150 2011-12-27 07:40:49 <BlueMatt> if ever there was a time to get a review of bitcoin, 0.6 would be it
151 2011-12-27 07:47:03 <osmosis> cool
152 2011-12-27 07:49:26 <wumpus> yeah...
153 2011-12-27 07:50:46 <BlueMatt> we could probably get the cash together if gavin tried
154 2011-12-27 07:51:09 <osmosis> who is the 'professional' that would be hired?
155 2011-12-27 07:51:12 <BlueMatt> or if ie luke-jr plus [Tycho] required it before implementing it on their pools
156 2011-12-27 07:51:57 <BlueMatt> osmosis: one would buy a professional who does security analysis for a living (there are a ton of those out there)
157 2011-12-27 07:52:01 <wumpus> good question osmosis, I'm don't think randomly throwing money at it is going to solve it
158 2011-12-27 07:52:20 <osmosis> I thought BlueMatt was the professional.
159 2011-12-27 07:52:25 <BlueMatt> no, someone would need to find which firms have good reputations
160 2011-12-27 07:52:30 <BlueMatt> osmosis: hahahaha
161 2011-12-27 07:53:07 <wumpus> but we should recommend heavy code review, at the least
162 2011-12-27 07:53:09 <wumpus> and not rush it in
163 2011-12-27 07:53:30 <BlueMatt> well its already in...
164 2011-12-27 07:53:36 <BlueMatt> so we better review before release
165 2011-12-27 07:53:45 <wumpus> maybe disable it for now, it's too dangerous for our own good
166 2011-12-27 07:54:09 <BlueMatt> OP_EVAL is essentially gavin's highest priority ever
167 2011-12-27 07:54:20 <osmosis> just release it as 'beta'
168 2011-12-27 07:54:23 <wumpus> okay
169 2011-12-27 07:54:34 <osmosis> no one will complain if it says beta right on it.
170 2011-12-27 07:54:41 <wumpus> but how did something like ScriptInner(recursionDepth++) come through code review?
171 2011-12-27 07:54:48 <BlueMatt> no bitcoin is stable
172 2011-12-27 07:56:10 <wumpus> well we do vet pull requests
173 2011-12-27 07:56:31 <BlueMatt> not really
174 2011-12-27 07:56:48 <edcba> ;;bc,mtgox
175 2011-12-27 07:56:49 <gribble> {"ticker":{"high":4.07425,"low":3.9002,"avg":3.99902409,"vwap":3.999648042,"vol":38759,"last_all":4.03613,"last_local":4.03613,"last":4.03613,"buy":4.03613,"sell":4.0371}}
176 2011-12-27 07:57:04 <wumpus> sigh, okay whatever... it's all good, nothing to see here
177 2011-12-27 08:32:37 <red__> hi, what is the minimum BTC Transaktion with the standart Client?
178 2011-12-27 08:34:13 <edcba> there is no minimum afaik but you will have to pay a fee
179 2011-12-27 08:34:35 <edcba> minimum being 1e-8 BTC iirc
180 2011-12-27 08:35:25 <edcba> now the fee thingie may depend on "standard client" :)
181 2011-12-27 08:36:10 <red__> standart= download from bitcoin.org
182 2011-12-27 08:36:21 <edcba> ie a miner can accept a transaction without fee even if transaction is small
183 2011-12-27 08:36:25 <red__> 1e-8 means?
184 2011-12-27 08:36:41 <edcba> 0.00000001
185 2011-12-27 08:36:50 <extor> Can someone tell me what cart system this guy is using and whether it's free or paid? http://library-list.com/
186 2011-12-27 08:39:22 <red__> well i got a problem my Client wants a minimum fee from 0.0005 BTC  even if the settings say fee is 0  - any idea why?
187 2011-12-27 08:40:45 <edcba> maybe your client sux or maybe there is a bug
188 2011-12-27 08:42:18 <red__> okay but this should not be usual right?
189 2011-12-27 08:47:32 <BlueMatt> red__: that is normal, see the fee page on the wiki
190 2011-12-27 08:50:10 <red__> okay thanks
191 2011-12-27 11:39:12 <CIA-100> bitcoinjs/node-bitcoin-p2p: Danny Navarro master * r12527b1 / lib/node.js : Not every block has version 1. Fixes #50. ... https://github.com/bitcoinjs/node-bitcoin-p2p/commit/12527b1b069be70265150b714cfaa76b3d9f2d07
192 2011-12-27 11:39:13 <CIA-100> bitcoinjs/node-bitcoin-p2p: Danny Navarro master * rdf28101 / lib/script.js : Missing assignment to `len` for `OP_PUSHDATA4`. - http://git.io/ZfRVXw https://github.com/bitcoinjs/node-bitcoin-p2p/commit/df2810162c6ff961c7457a700cfe7f87385b3535
193 2011-12-27 12:41:06 <Diablo-D3> http://falkvinge.net/2011/09/27/never-trust-a-vpn-provider-that-doesnt-accept-bitcoin/
194 2011-12-27 13:24:06 <wladston> guys, is there any way to set the transaction fee I'm willing to pay with bitcoind sendtoaddress ?
195 2011-12-27 13:24:39 <wladston> right now, when I try to send some amount using json-rpc, I get no warning about the fee being applied
196 2011-12-27 13:36:05 <wladston> I can't find a way to avoid sending compulsory transaction fee using bitcoind. :(
197 2011-12-27 13:36:52 <gmaxwell> wladston: There isn't a way with the GUI either. If it's _compulsory_ it's because its confident that the transaction will get stuck without it.
198 2011-12-27 13:37:11 <gmaxwell> (though the GUI does give you the option to abort in that case)
199 2011-12-27 13:37:20 <wladston> gmaxwell: the GUI gives me a warning saying the amount of the fee
200 2011-12-27 13:37:22 <edcba> confident ?
201 2011-12-27 13:37:25 <edcba> how ?
202 2011-12-27 13:37:31 <TD> because the rules say it will be stuck
203 2011-12-27 13:37:38 <wladston> gmaxwell: bitcoind gives no warning at all
204 2011-12-27 13:37:44 <gmaxwell> edcba: by applying the same fee rule that it would use for relaying.
205 2011-12-27 13:38:01 <edcba> wait there is a relaying fee now ?
206 2011-12-27 13:38:03 <gmaxwell> wladston: I know. But thats not what it appeared you were asking about.
207 2011-12-27 13:38:33 <wladston> gmaxwell: sorry :) my question is how can I know the transaction fee of a senttoaddress before it gets sent
208 2011-12-27 13:39:06 <gmaxwell> edcba: ... No. There is an automatic rule which stops DDOS attacks by preventing rapid back to back transactions of the same coin, unless a fee is provided.
209 2011-12-27 13:40:00 <gmaxwell> edcba: without it I could simply type while true; do bitcoind sendtoaddress `bitcoind getnewaddress`;done  and pretty much take out bitcoin
210 2011-12-27 13:41:07 <edcba> so you can stop a legitimate transaction if you have same coin ?
211 2011-12-27 13:41:24 <gmaxwell> wladston: You can't currently, and thats because getting a new txn in or getting a new block may drastically change the coin selection... so even if you could ask it, the answer would potentially be invalid by the time you got your answer.
212 2011-12-27 13:41:27 <edcba> or at least stop spreading
213 2011-12-27 13:42:36 <wladston> gmaxwell: that could be a major problem, no ? What is the blocksize is getting closer to 500Kb and I loose 2BTC for trying to send 0.5BTC ?
214 2011-12-27 13:42:58 <gmaxwell> edcba: bitcoin nodes will not relay transactions which look like a DOS attack.
215 2011-12-27 13:43:29 <gmaxwell> wladston: er. The compulsory fees needed for anti-ddos are 0.0005 btc.
216 2011-12-27 13:43:38 <edcba> why not just use some bayesian thingie ?
217 2011-12-27 13:44:03 <edcba> maybe too easy to circumvent
218 2011-12-27 13:44:03 <wladston> gmaxwell: I know, but I've seen on the wiki some cases of very high fee being applied
219 2011-12-27 13:44:32 <wladston> gmaxwell: how can I assure that my fee won't be greater than 0.0005 BTC ?
220 2011-12-27 13:44:45 <gmaxwell> edcba: none of this is recent.
221 2011-12-27 13:45:00 <edcba> yes i know
222 2011-12-27 13:45:08 <edcba> it's been a while i looked at it
223 2011-12-27 13:47:21 <gmaxwell> wladston: how? go read the fee logic in main.h
224 2011-12-27 13:47:25 <gmaxwell> ::shrugs::
225 2011-12-27 13:47:51 <wladston> gmaxwell: so I have to implement fee calculations outside of bitcoind ?
226 2011-12-27 13:47:56 <gmaxwell> wladston: In any case, all of the reported "high fees" I've seen have been people confused by change in block explorer.
227 2011-12-27 13:48:09 <gmaxwell> wladston: No, you can't implement fee calculations outside of bitcoind.
228 2011-12-27 13:48:41 <gmaxwell> 06:41 < gmaxwell> wladston: You can't currently, and thats because getting a new txn in or getting a new block may drastically change the coin  selection... so even if you could ask it, the answer would potentially be invalid by the time you got your answer.
229 2011-12-27 13:49:40 <sipa> the right solution is to be able to create a transaction in "preview" mode, which allows you to inspect the transacton before it is sent out
230 2011-12-27 13:49:53 <sipa> and then give the option to either cancel or proceed
231 2011-12-27 13:50:26 <wladston> sipa: thanks :) what's the command for creating a preview sendtoaddress ?
232 2011-12-27 13:50:36 <sipa> it doesn't exist yet...
233 2011-12-27 13:50:54 <sipa> i'm just saying what would need to be implemented to solve the issue you're having
234 2011-12-27 13:50:56 <lianj> someone at 28c3?
235 2011-12-27 13:51:29 <wladston> sipa: do you have any services based on bitcoins ? how do you handle this issue ?
236 2011-12-27 13:51:39 <gmaxwell> sipa: right, I suppose it could be made tolerable if the preview only locked the inputs until the next send.
237 2011-12-27 13:51:48 <sipa> wladston: i only run bitcoin.sipa.be
238 2011-12-27 13:51:54 <sipa> no payment handling stuff
239 2011-12-27 13:52:13 <sipa> but it's a nice idea that's been around fro a while
240 2011-12-27 13:52:15 <gmaxwell> wladston: people running services just take the fees as a cost of doing business (and sometimes pass them on to customers e.g. 0.01 for withdraws, at a profit).
241 2011-12-27 13:52:18 <helo> if random bits were written to a wallet where the encrypted keys are stored, the wallet would be indistinguishable from a wallet with encrypted keys intact, right?
242 2011-12-27 13:52:18 <sipa> i guess i could implement it
243 2011-12-27 13:52:42 <sipa> helo: indeed, unless you knoz the key
244 2011-12-27 13:53:23 <helo> if such wallets were common, it might provide some plausible deniability and waste the resources of attackers
245 2011-12-27 13:53:33 <wladston> gmaxwell: it still sounds very dangerous. if my clients mange to create outgoing transactions with generate a big fee ( since it's compulsory), it's possible that I would end up owing money
246 2011-12-27 13:53:56 <sipa> it won't ever let you go negative
247 2011-12-27 13:54:07 <wladston> sipa: how ?
248 2011-12-27 13:54:19 <sipa> that's sinmply impossible
249 2011-12-27 13:54:28 <sipa> the protocol does not allow you to send coins you don't have
250 2011-12-27 13:54:33 <gmaxwell> wladston: I think you're over reacting because you don't understand how it works, go walk through the code and see the fee that it would apply.
251 2011-12-27 13:55:06 <wladston> I have a cliend with one of those bitcoind accounts. If I try to transfer everything in it to an address, it will do so, getting the fee from the main wallet.dat
252 2011-12-27 13:55:25 <sipa> oh yes
253 2011-12-27 13:55:33 <gmaxwell> wladston: You can also insert a one line change to make it fail if the fee would be higher than 0.01 if you like... though it takes a 20kbyte transaction to make the fee that large.
254 2011-12-27 13:55:35 <sipa> the guarantee is only for the entire wallet
255 2011-12-27 13:56:10 <gmaxwell> (and if something about your service is reliably allowing customers to produce 20kbyte transactions, then you ought to fix it)
256 2011-12-27 13:56:46 <wladston> gmaxwell: right. And how could I do that ?
257 2011-12-27 13:56:59 <gmaxwell> wladston: and how could you do what?
258 2011-12-27 13:57:16 <wladston> gmaxwell:  insert a one line change to make it fail if the fee would be higher than 0.01
259 2011-12-27 13:59:59 <wladston> I just have no idea how the transaction size would grow
260 2011-12-27 14:00:11 <wladston> and I wanted to launch my service free of charge at the start
261 2011-12-27 14:00:38 <wladston> without the risk of getting backrupt :D
262 2011-12-27 14:01:40 <gmaxwell> wladston: e.g. untested, http://pastebin.com/EkD45McZ
263 2011-12-27 14:01:53 <gmaxwell> wladston: but I think you're being irrational.
264 2011-12-27 14:02:47 <wladston> gmaxwell: maybe ... I would like if you could help me understand better
265 2011-12-27 14:03:10 <wladston> gmaxwell: because from what I've read so far, there is no upper limit for the transaction fee
266 2011-12-27 14:03:28 <wladston> gmaxwell: and it gets taken from the wallet.dat compulsively
267 2011-12-27 14:03:52 <wladston> gmaxwell: so I can't see how that isn't a problem for automated bitcoind applications
268 2011-12-27 14:03:56 <gmaxwell> wladston: Sure, there is. But the upper limit isn't relevant.
269 2011-12-27 14:04:22 <gmaxwell> wladston: because in practice the required fee is almost always zero, and when its not it's almost always 0.0005.
270 2011-12-27 14:04:56 <gmaxwell> It can be larger, when the transaction data is very large. But the software makes an effort to minimize the data size.
271 2011-12-27 14:05:54 <nanotube> <wumpus> [00:37:35] could add the actual block time/date to the "transaction details" if it's not yet in there <- yes please.! :)
272 2011-12-27 14:06:13 <wladston> gmaxwell: so if I charge my clients a withdraw fee of 0.0005 I can be safe ?
273 2011-12-27 14:07:17 <wladston> gmaxwell: also I can't see if my service could be attacked by a malicious user trying to create large transactions
274 2011-12-27 14:07:30 <gmaxwell> so the only way that I'm aware of to end up with a 'large' fee is e.g. to have a wallet with nothing other than tiny dust (e.g. 1e-8) inputs confirmed.
275 2011-12-27 14:07:46 <gmaxwell> one sec and I'll figure out the current maximum fee it could come up with.
276 2011-12-27 14:08:51 <wladston> the way I'm coding it now, the service could be used like an online wallet, with the client being able to deposit and withdraw at any times from his account.
277 2011-12-27 14:11:08 <gmaxwell> wladston: okay, the _highest_ it can come up with right now appears to be 0.05 BTC.
278 2011-12-27 14:11:26 <wladston> gmaxwell: ! not as much as I thought
279 2011-12-27 14:12:07 <gmaxwell> wladston: sure, but to force you to use tiny inputs he'd have to prevent your wallet from containing anything else.
280 2011-12-27 14:12:26 <gmaxwell> That limit arises from,
281 2011-12-27 14:13:01 <wladston> gmaxwell: I think I'll settle with charging a 0.005 withdraw fee
282 2011-12-27 14:14:04 <gmaxwell> where MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2; MAX_BLOCK_SIZE = 1000000; and nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;  where nBaseFee=MIN_TX_FEE and MIN_TX_FEE=50000
283 2011-12-27 14:15:09 <gmaxwell> I suppose it would be useful to document that, just to help calm people's nerves.
284 2011-12-27 14:15:33 <wladston> gmaxwell: I wonder how instawallet handles this, since their service is apparently "free"
285 2011-12-27 14:16:01 <gmaxwell> wladston: if your wallet has a good amount of older inputs in it, you'll simple never run into this.
286 2011-12-27 14:16:30 <wladston> interesting
287 2011-12-27 14:19:03 <gmaxwell> The fees are only required when you fail the anti-ddos rules (e.g. respending inputs that arrived too recently). You need, on average, about one bitcoin day (one bitcoin for one day, two bitcoin for a half day, a half bitcoin for two days, etc) of sit-still-time to get a typical transaction past the anti-ddos rule.
288 2011-12-27 14:20:07 <wladston> gmaxwell: got it. Thinking here on how to best handle this in the webapp
289 2011-12-27 14:30:40 <helo> is the age of the inputs available used to determine which inputs to spend?
290 2011-12-27 14:31:44 <gmaxwell> Yes, though only in a limited way.
291 2011-12-27 14:31:57 <wladston> gmaxwell: thanks for the help :) going to class now. hopefully I'll manage to launch the service with a very low fee.
292 2011-12-27 14:32:19 <helo> i think unless your webapp is being used to generate spam, the issue won't arise
293 2011-12-27 14:32:26 <gmaxwell> It runs the selection algorithim multiple times, trying to use older inputs first.
294 2011-12-27 14:32:33 <wladston> gmaxwell: the thing is I didn't want to change the incoming deposits ... nor the outgoing withdraws ... just the use of the service
295 2011-12-27 14:33:17 <wladston> helo: yeah, maybe I would have to thing of a way to block spam-users
296 2011-12-27 14:33:40 <wladston> halo: because the way it is now a user could deposit and withdraw multiple times generating spam
297 2011-12-27 14:34:22 <wladston> off I go :)
298 2011-12-27 14:38:32 <genjix> wumpus: you have a bash script scripts/qt/make_windows_icon.py
299 2011-12-27 14:38:36 <genjix> should end in .sh
300 2011-12-27 14:38:41 <genjix> fyi
301 2011-12-27 14:38:48 <wumpus> lol
302 2011-12-27 14:38:54 <wumpus> yes
303 2011-12-27 14:38:58 <sipa> just calculated some statistics from my dnsseeder's crawler
304 2011-12-27 14:39:02 <wumpus> I generally write python scripts, so I'm used to .py
305 2011-12-27 14:39:15 <sipa> most nodes run 0.3.23 :(
306 2011-12-27 14:39:23 <wumpus> ouch :s
307 2011-12-27 14:39:27 <sipa> 2787 reachable ones
308 2011-12-27 14:39:42 <sipa> 1645 at 0.3.24
309 2011-12-27 14:39:55 <sipa> 1425 at 0.4.0
310 2011-12-27 14:40:07 <sipa> 810 at 0.5.1
311 2011-12-27 14:40:20 <sipa> 432 at 0.5.0.1
312 2011-12-27 14:40:39 <sipa> 389 at 0.3.21
313 2011-12-27 14:41:05 <wumpus> seems people are reluctant to upgrade
314 2011-12-27 14:41:20 <genjix> or what they have already works
315 2011-12-27 14:41:23 <gmaxwell> wumpus: they may have no idea a new version is available.
316 2011-12-27 14:41:35 <TD> sipa: there's a site that tracks those stats
317 2011-12-27 14:41:47 <sipa> TD: i know, i should compare the numbers
318 2011-12-27 14:41:51 <TD> http://bitcoinstatus.rowit.co.uk/
319 2011-12-27 14:42:04 <TD> it's been showing a steady decline in the number of reachable nodes
320 2011-12-27 14:42:32 <TD> it may be an issue with the stat collector
321 2011-12-27 14:42:35 <wumpus> genjix: yes, so they are reluctant to upgrade
322 2011-12-27 14:42:49 <TD> is there an issue with UPnP?
323 2011-12-27 14:42:52 <wumpus> it makes sense, in a twisted way
324 2011-12-27 14:43:28 <gmaxwell> TD: Yes. I'd fix it but don't have any way to test it.
325 2011-12-27 14:43:38 <TD> you don't have a upnp capable router?
326 2011-12-27 14:43:45 <gmaxwell> TD: the UPNP just fires off once. So once the router expires it, its gone.
327 2011-12-27 14:43:50 <TD> ah
328 2011-12-27 14:43:55 <TD> how quickly do the entries expire?