1 2012-11-12 00:00:29 <sipa> because if not, application will make assumptions about what kind of filter they will get (if the default is one that is good for 1000 items, it will deteriorate quickly when 10000 are in the filter
  2 2012-11-12 00:01:44 <sipa> but if it is not specified, no assumption at all can be made, and the server is not given any information, so cannot be assumed to make a meaningful guess
  3 2012-11-12 00:03:37 <BlueMatt> frankly, Im not sure why filteradd was created in the first place...Id much rather it have not been there since the beginning
  4 2012-11-12 00:03:49 <BlueMatt> (not having it there forces correct behavior...)
  5 2012-11-12 00:04:45 <BlueMatt> (and no, Im not the one who created it)
  6 2012-11-12 00:05:05 <sipa> if you dob't expect frequent matches, then filteradd probably has lower overhead than constantly sending a new filter
  7 2012-11-12 00:06:34 <sipa> then again, just having constant client-supplied filters makes everything a lot more clean to reason about
  8 2012-11-12 00:06:45 <Diablo-D3> so
  9 2012-11-12 00:07:30 <Diablo-D3> are there any companies who are actually trying to take on paypal using bitcoin and actually succeeding?
 10 2012-11-12 00:11:25 <BlueMatt> sipa: meh, filters are so small that the overhead to keep a local copy of your filter and add/resend as necessary is very low
 11 2012-11-12 00:22:40 <sipa> BlueMatt: there are even very efficient encodings to send incremental updates to a bloom filter
 12 2012-11-12 00:23:17 <BlueMatt> yes...we could overoptimize like crazy, but...
 13 2012-11-12 02:20:02 <Luke-Jr> this code is facepalm-worthy: http://pastebin.com/4kRNsLKt
 14 2012-11-12 02:20:53 <BlueMatt> where the hell did you see that?
 15 2012-11-12 02:23:32 <Luke-Jr> BlueMatt: wizkid057's CPPSRB implementation for Eligius <.<
 16 2012-11-12 02:23:46 <wizkid057> lol
 17 2012-11-12 02:23:52 <wizkid057> leave me alone it was like, 4AM
 18 2012-11-12 02:24:00 <Luke-Jr> XD
 19 2012-11-12 02:24:15 <wizkid057> and blockexplorer.com says reward halfs on block 209999
 20 2012-11-12 02:24:21 <gribble> 25.00000000
 21 2012-11-12 02:24:21 <wizkid057> ;;web fetch http://blockexplorer.com/q/bcperblock/209999
 22 2012-11-12 02:26:25 <wizkid057> wow, actually I commited that at 5:10AM
 23 2012-11-12 02:26:27 <wizkid057> lol
 24 2012-11-12 02:29:13 <wizkid057> so yeah, is blockexplorer.com wrong on this then?
 25 2012-11-12 02:33:22 <lianj> 5000000000 / (2 ** (209999 / 210000.0).floor)
 26 2012-11-12 02:33:27 <lianj> yes
 27 2012-11-12 02:33:57 <lianj> or it depends if block 0 is 0 or 1
 28 2012-11-12 02:34:05 <wizkid057> block 0 is 0? heh
 29 2012-11-12 02:36:52 <Luke-Jr> genesis block is 0
 30 2012-11-12 02:36:55 <Luke-Jr> confirmed in code
 31 2012-11-12 02:37:17 <lianj> so bbe is off
 32 2012-11-12 02:37:49 <wizkid057> Luke-Jr: http://pastebin.com/bG9mz0PK
 33 2012-11-12 02:37:53 <wizkid057> HAPPY NOW?!
 34 2012-11-12 02:37:55 <wizkid057> ;P
 35 2012-11-12 02:38:24 <lianj> https://pastee.org/55tch is from my specs, hope they are right then :)
 36 2012-11-12 02:39:02 <Luke-Jr> wizkid057: #define block_reward(height) (5000000000>>(height/210000))
 37 2012-11-12 02:39:08 <wizkid057> ...
 38 2012-11-12 02:39:09 <wizkid057> lol
 39 2012-11-12 02:39:10 <Luke-Jr> j/k I don't suggest that
 40 2012-11-12 02:41:19 <cjd> I would hate typing 'unsigned long long' all the time
 41 2012-11-12 02:41:26 <wizkid057> commit a9701b8c0eb763d390712e7476f62bba4cda3bfc --- Author: Jason Hughes <wizkid057@gmail.com> --- Date:   Mon Nov 12 03:41:03 2012 +0000
 42 2012-11-12 02:42:07 <cjd> uint64_t autotypes for me now
 43 2012-11-12 02:42:35 <wizkid057> i actually like using the built in types as a personal preference
 44 2012-11-12 02:42:54 <cjd> yeah, it's valid
 45 2012-11-12 02:43:02 <cjd> just be careful of 'long'
 46 2012-11-12 02:43:25 <etotheipi_> what is the "proper" way to trigger uint*_t types in windows?
 47 2012-11-12 02:43:46 <cjd> mingw32?
 48 2012-11-12 02:44:12 <cjd> or use nacl which defines crypto_uint*.h and does it very thoroughly
 49 2012-11-12 02:44:12 <etotheipi_> I end up just defining them myself in a windows-specific preprocessor, but I know it's hacky
 50 2012-11-12 02:44:30 <gmaxwell> Luke-Jr: your macro is underparentheized. :P
 51 2012-11-12 02:44:57 <cjd> *shrug* @ hacky, I do stuff like that constantly, either it's maintainable or it's not
 52 2012-11-12 02:46:48 <cjd> https://github.com/cjdelisle/cnacl/blob/master/inttypes/signed.h <-- as usual, djb has the most solid way to define integers possible
 53 2012-11-12 02:47:07 <cjd> make little test apps which bit shift until the 1 falls off the high side
 54 2012-11-12 02:47:42 <cjd> whether or not there is a system so insane that it's really needed is up for debate
 55 2012-11-12 02:49:58 <gmaxwell> cjd: yea, by writing code with undefined behavior& good job there.
 56 2012-11-12 02:50:41 <gmaxwell> (overflowing a signed type is undefined and will, here and there, get you surprising optimizations)
 57 2012-11-12 02:51:13 <cjd> indeed
 58 2012-11-12 02:51:32 <cjd> not actually my code though, I'm just trying to save it from it's build system
 59 2012-11-12 02:54:10 <Luke-Jr> gmaxwell: what? no it isn't :/
 60 2012-11-12 02:54:39 <cjd> hmm he's not shifting it off the edge, he's using addition
 61 2012-11-12 02:54:50 <Luke-Jr> wizkid057: C99 stdlib doesn't count as built in?
 62 2012-11-12 02:55:04 <Luke-Jr> etotheipi_: #include <stdint.h>
 63 2012-11-12 02:55:57 <cjd> hmm indeed still overflowing it
 64 2012-11-12 02:55:59 <cjd> ohwell
 65 2012-11-12 02:56:05 <Luke-Jr> gmaxwell: oh, I see why; I need to use (height) in case of internal maths
 66 2012-11-12 02:56:21 <gmaxwell> cjd: Singed overflow is _generally_ undefined, not just via shifts... even in C89.
 67 2012-11-12 02:56:32 <gmaxwell> Luke-Jr: yes.
 68 2012-11-12 02:57:15 <cjd> I was thinking about that the other day, do I get a tiny performance improvement using for (int i = 0; i < ....   vs. for (uint32_t i = 0;...
 69 2012-11-12 02:57:17 <cjd> ?
 70 2012-11-12 02:57:17 <gmaxwell> lest someone put 2016<<4 there.
 71 2012-11-12 02:57:27 <gmaxwell> cjd: sometimes, yes.
 72 2012-11-12 02:58:57 <gmaxwell> cjd: there are some cases where the compiler can figure out that the loop runs, say, exactly 4 times or infinity and if the counter is signed it assumes it won't overflow and can then unroll the loop.
 73 2012-11-12 02:59:01 <Luke-Jr> cjd: if i were a compiler, I would interpret that macro as 'jmp <this instruction>' as long as bits was bigger than the size :D
 74 2012-11-12 02:59:44 <cjd> hehe
 75 2012-11-12 02:59:51 <Luke-Jr> gmaxwell: unsigned overflow is well-defined? O.o
 76 2012-11-12 03:00:02 <gmaxwell> Luke-Jr: yes! unsigned is...
 77 2012-11-12 03:00:16 <cjd> yeah, we'd be in some serious trouble otherwise
 78 2012-11-12 03:00:16 <Luke-Jr> that's annoying. we just changed a bunch of for loops to use unsigned types :<
 79 2012-11-12 03:00:51 <gmaxwell> Luke-Jr: well we did it in places where it caused mixed types otherwise.
 80 2012-11-12 03:00:55 <cjd> stuff like the sha256 core is full of ints which roll over
 81 2012-11-12 03:01:08 <Luke-Jr> gmaxwell: coulda cast to a signed type? :P
 82 2012-11-12 03:02:30 <gmaxwell> Luke-Jr: sure. ::shrugs:: I generally like to avoid the casts. I wouldn't generally worry about the optimization behavior of signed vs unsigned... far more concerning is people getting the promotion rules wrong when signed/unsigned are mixed. Casts don't make that go away: someone will forget one sooner or later.
 83 2012-11-12 03:05:21 <cjd> oh, I was wondering if you had an example of doing some arbitrary computation with templates which was actually useful? I've seen the factorial example on stackoverflow but it was not very impressive.
 84 2012-11-12 03:17:41 <Diablo-D3> so
 85 2012-11-12 03:17:59 <Diablo-D3> I wonder if I could go buy an asic unit and get it hear early
 86 2012-11-12 03:18:32 <Luke-Jr> if you weren't a troll, probably
 87 2012-11-12 07:55:20 <sipa> BlueMatt: but even without explicit filteradd, there is still an implicit filteradd (txids of matched outputs)
 88 2012-11-12 07:55:50 <sipa> BlueMatt: the client also has to be aware of those if it wants to maintain filter efficiency
 89 2012-11-12 09:14:30 <x18882> hey guys, what's the most secure client usable today, after bitcoin-qt (which is too heavy on my machine)?
 90 2012-11-12 09:15:52 <x18882> sorry wrong channel, i meant to ask this in #bitcoin
 91 2012-11-12 09:16:11 <x18882> although if someone wants to chime it, go ahead ;)
 92 2012-11-12 09:22:50 <SomeoneWeird> define secure, x18882
 93 2012-11-12 09:26:05 <xisalty> Idiot proof
 94 2012-11-12 09:35:51 <x18882> let's define a perfectly secure client as "never been stolen from" "has no known exploits", "uses high encryption standards", "is peer reviewed"
 95 2012-11-12 09:37:29 <x18882> I know these are quite strict requirements, and it's probably too early to get clients with that level of security, but after bitcoin-qt, what other client is closest to this definition?
 96 2012-11-12 09:39:39 <sipa> multibit has a better security model imho, but has no wallet encryption
 97 2012-11-12 09:40:14 <sipa> electrum has wallet encryption and deterministic wallets, but a less secure model (though it's improving)
 98 2012-11-12 09:40:39 <cjd> Bitcoinj? java is memory safe and it's a pretty old client.. thoughts?
 99 2012-11-12 09:41:02 <sipa> bitcoinj is not a client, it's a library
100 2012-11-12 09:41:07 <sipa> and multibit uses bitcoinj
101 2012-11-12 09:41:10 <cjd> ahh ok
102 2012-11-12 09:41:45 <TD> sipa: actually it does do wallet encryption now
103 2012-11-12 09:42:12 <TD> there's a pullreq open to add that to bitcoinj
104 2012-11-12 09:42:17 <TD> i just didn't have time to review it yet
105 2012-11-12 09:42:34 <TD> once it's merged, i guess it'd meet x18882s requirements
106 2012-11-12 09:44:05 <x18882> thanks
107 2012-11-12 09:45:19 <x18882> i might give multibit a try (although i'm reluctant to install a Java environment on my machine, seeing how many exploits are found each month)
108 2012-11-12 09:45:43 <sipa> TD: what do you think about a flag in the bloom filter to match only unspent outputs? not every client is necessarily interested in retrieving its entire history
109 2012-11-12 09:46:28 <x18882> also, what's less secure about the electrum model? i mean, what's the risk with its implementation?
110 2012-11-12 09:47:51 <sipa> x18882: it relies on a central server, which can have privacy issues, and there used to be no way of verifying whether what that server tells you is correct (it may make you believe you receive money while you didn't)
111 2012-11-12 09:48:49 <sipa> x18882: recently they added SPV verification to electrum though (which is the same type of verification multibit/bitcoinj use), but not every electrum server supports this yet, and i'm not sure how peer-reviewed it is
112 2012-11-12 09:50:49 <x18882> by central server you mean that if it goes down, every other server goes down too??
113 2012-11-12 09:52:57 <sipa> no, but the client needs a special server to operate, and only connects to this
114 2012-11-12 09:53:18 <sipa> an electrum client is not a node in the bitcoin network - the electrum server is the node
115 2012-11-12 09:54:21 <x18882> I see
116 2012-11-12 10:02:36 <TD> x18882: the exploits for java are relevant only if you have the java plugin enabled
117 2012-11-12 10:02:46 <TD> x18882: if you use modern browsers like chrome, you won't have that, so it's ok
118 2012-11-12 10:03:12 <TD> sipa: i guess so. we have to be wary of feature creep though
119 2012-11-12 10:17:53 <slush> Luke-Jr: "Stratum requires notifies every 30 seconds" - - no, it doesn't require, it's just how me and Eleuthria implemented this.
120 2012-11-12 12:06:02 <abrkn> can an address become invalid, or can i assume it's good if validateaddress ever returns true?
121 2012-11-12 12:06:23 <Diablo-D3> its even better
122 2012-11-12 12:06:32 <Diablo-D3> addresses can be valid even if no one holds the private key
123 2012-11-12 12:08:47 <abrkn> ok
124 2012-11-12 12:09:02 <abrkn> how many sends can i safely do in one transaction? (sendmany)???
125 2012-11-12 12:09:10 <gmaxwell> abrkn: it only validates that the address has valid syntax.  Its generally inadvisable to send coin to an address that hasn't just been given to you by the recipent for the purpose of recieving _this_ payment.
126 2012-11-12 12:09:36 <abrkn> gmaxwell: ok
127 2012-11-12 12:10:31 <gmaxwell> abrkn: the number of outputs you can fit into a send many depends on the number and kinds of inputs you're redeeming. It'll fail and return an error if you call it with too many.
128 2012-11-12 12:11:38 <abrkn> interesting
129 2012-11-12 12:23:05 <someone42> does anyone here have any test vectors for the BIP 0032 child key derivation function?
130 2012-11-12 12:25:29 <sipa> someone42: i do, but i haven't written them out in the BIP text
131 2012-11-12 12:27:54 <someone42> sipa: could you pastebin (or equivalent) them? I'd like to include them as unit tests
132 2012-11-12 12:30:17 <sipa> someone42: they're not very elaborate (just tests the derived public keys, and the corresponding public keys of the derived private keys), or nicely formatted, but this is from a unit test i wrote: https://github.com/sipa/bitcoin/blob/edbdc5313c02dc82104cfb6017ce3427bf323071/src/test/detwallet_tests.cpp
133 2012-11-12 12:31:52 <sipa> someone42: what are you working on?
134 2012-11-12 12:33:03 <someone42> sipa: thanks, it was what i was looking for
135 2012-11-12 12:33:28 <someone42> i'm working on the firmware for a dedicated hardware Bitcoin wallet
136 2012-11-12 12:34:34 <sipa> cool
137 2012-11-12 14:15:46 <abrkn> gahh: amounts are double-precision floating point numbers] code: -1 }
138 2012-11-12 14:16:05 <abrkn> sendmany { bob: 100 } <-- no bueno
139 2012-11-12 14:44:54 <BlueMatt> sipa: yes but, again, filter adding is so cheap and they are small enough that I dont really see even a phone-based client having any load generated by just re-sending filter entirely when it needs updated (which is hopefully almost never anyway)
140 2012-11-12 14:49:25 <sipa> BlueMatt: no, but in terms of transparency towards the client, filteradd() is a lot nicer than the implicit adding of txids, and i'd rather not get rid of that last
141 2012-11-12 14:50:33 <sipa> BlueMatt: just saying that if you have implicit adding, you may as well have filteradd
142 2012-11-12 14:51:02 <sipa> BlueMatt: not sure if we're arguing for the same thing or not :p
143 2012-11-12 14:52:30 <jouke> I am using the standard 0.6.3 client from bitcoin.org. Do I need to detachdb in order to upgrade to 7.1?
144 2012-11-12 14:52:56 <sipa> probably, yes
145 2012-11-12 14:53:09 <sipa> -detachdb on 0.6.3
146 2012-11-12 14:53:18 <abrkn> what's a reasonable way to track transactions in my own database using the rpc? i noticed the order of listtransactions isnt guaranteed, to using "listtransactions 100 numberseenbefore" to discover new ones is not stable
147 2012-11-12 14:53:31 <abrkn> so using*
148 2012-11-12 14:54:10 <BlueMatt> sipa: meh, I dont really mind filteradd remaining, but I feel like thinking about it much isnt worth it because its use should be highly discouraged anyway...
149 2012-11-12 14:54:43 <BlueMatt> sipa: Im not really against failing if you give filteradd without a filter...
150 2012-11-12 14:54:56 <sipa> BlueMatt: i think filteradd working without having provided a filter is much worse than just filteradd
151 2012-11-12 14:55:06 <sipa> filteradd is useful if you only need incremental changes
152 2012-11-12 14:55:35 <sipa> BlueMatt: also,.what do you think about a flag to limit a filter to matching only unspent outputs?
153 2012-11-12 14:55:36 <BlueMatt> well...again Im not a fan of using filteradd for incremental changes...its kinda incorrect behavior
154 2012-11-12 14:55:44 <sipa> why?
155 2012-11-12 14:55:56 <sipa> you have a deterministic wallet, precalculate hundred keys
156 2012-11-12 14:55:59 <BlueMatt> it breaks any anonymity you get from filters
157 2012-11-12 14:56:05 <sipa> right
158 2012-11-12 14:56:14 <BlueMatt> (which incremental adding, btw, does not)
159 2012-11-12 14:56:18 <sipa> that's a good point, but probably not everyone cares about that
160 2012-11-12 14:58:20 <gmaxwell> sipa: a flag matching just unspent makes a lot of sense, but I worry that its burdensom since you need to both consult the txout set and the blocks.
161 2012-11-12 14:58:47 <sipa> the txout set should be very accessible already
162 2012-11-12 14:59:48 <sipa> plus you can probably do things (in a later optimization) like making a read-only snapshot of the txout database, iterate through it, build a list of heights that have interesting transactions, and then only query those blocks from disk
163 2012-11-12 15:00:21 <sipa> (as serving empty block headers does not need access to on-disk blocks)
164 2012-11-12 15:00:32 <jouke> When I run with -detachdb, am I able to stop it trough rpc?
165 2012-11-12 15:00:44 <sipa> jouke: doesn't matter; just shutdown cleanly
166 2012-11-12 15:01:16 <jouke> I don't really know what that means.
167 2012-11-12 15:01:24 <sipa> jouke: i.e. don't crash
168 2012-11-12 15:01:27 <jouke> Can I ctrl+c it?
169 2012-11-12 15:01:30 <sipa> yes
170 2012-11-12 15:01:43 <sipa> don't pull the power cable, don't kill -KILL, ...
171 2012-11-12 15:01:56 <jouke> because atm I can't connect to it trough rpc
172 2012-11-12 15:02:04 <sipa> why not?
173 2012-11-12 15:02:14 <jouke> I don't know
174 2012-11-12 15:02:22 <jouke> Ah, now I can
175 2012-11-12 15:02:32 <jouke> I guess it was still starting up
176 2012-11-12 15:02:32 <sipa> if it hasn't started up yet, wait
177 2012-11-12 15:02:34 <sipa> ok
178 2012-11-12 15:03:32 <edcba> maybe we should remain bitcoins as karma
179 2012-11-12 15:03:37 <edcba> rename
180 2012-11-12 15:04:27 <sipa> gmaxwell: then again, maybe serving just unspent outputs risks making people not keep a local wallet at all (what if i have a local wallet with formerly unspent outputs, i sync, and don't get to see the transactions that spend them?)
181 2012-11-12 15:05:20 <BlueMatt> sipa: yea, many people wont care, but implementations dont know whether the user cares or not, so implementations should always be careful to maintain privacy; re: unspent outputs, do you mean you match everything as we currently do but only match if its unspent...Im not a huge fan there, it could cause more cost for serving nodes if you dont keep a db of that (which ultraprune does not?)
182 2012-11-12 15:06:06 <sipa> BlueMatt: the one thing ultraprune keeps first and foremost is a set of unspent transaction outputs...
183 2012-11-12 15:06:49 <gmaxwell> BlueMatt: it means you could satisify those queries off pruned nodes... pretty nice optimization there.
184 2012-11-12 15:07:14 <sipa> gmaxwell: still needs the actual block data
185 2012-11-12 15:07:20 <sipa> for the transactions being served
186 2012-11-12 15:07:28 <BlueMatt> sipa: ahh, thought about that wrong sorry...
187 2012-11-12 15:07:54 <sipa> gmaxwell: as ultraprune data does not have full transactions or merkle paths
188 2012-11-12 15:08:08 <sipa> but you could use the ultraprune data as index for finding the rest
189 2012-11-12 15:09:58 <sipa> by the way... is there a service bit for serving merkle blocks?
190 2012-11-12 15:10:13 <sipa> or has that been considered? (i vaguely remeber something like that)
191 2012-11-12 15:10:50 <BlueMatt> gmaxwell: meh, you shouldnt be doing initial sync off a pruned noide
192 2012-11-12 15:10:57 <BlueMatt> node*
193 2012-11-12 15:11:07 <sipa> what do you mean by pruned node in the first place?
194 2012-11-12 15:11:15 <sipa> one which doesn't have all blocks?
195 2012-11-12 15:11:23 <gmaxwell> One that can't serve historic transactions.
196 2012-11-12 15:11:24 <sipa> if it has the blocks you need, there is no problem
197 2012-11-12 15:11:45 <sipa> if it doesn't want to serve blocks at all, there is no way to sync from it
198 2012-11-12 15:12:42 <sipa> but if someone is only interested in knowing unspent transaction outputs, i could iterate my ultraprune db instead of iterating all blocks
199 2012-11-12 15:12:51 <sipa> if anything, that's a massive optimization for the server
200 2012-11-12 15:13:10 <sipa> (assuming the number of blocks with relevant unspent transactions is small)
201 2012-11-12 15:16:48 <sipa> two reasons against this idea: it means serving blocks to other nodes means having an UTXO database , so you can't perfectly separate the archive function and the validation function anymore
202 2012-11-12 15:17:15 <sipa> and another: it is not very useful for syncing existing wallets, as those want to know about their old txouts being spent
203 2012-11-12 15:20:48 <sipa> afk
204 2012-11-12 16:01:53 <helo> BAM
205 2012-11-12 16:04:57 <MATTMATT> I WOULD LIKE TO DISCUSS DEVELOPMENT
206 2012-11-12 16:05:08 <BlueMatt> FUCK YOU
207 2012-11-12 16:05:34 <daybyter> ???
208 2012-11-12 16:06:49 <BlueMatt> (hes sitting next to me and just wanted to be a dick)
209 2012-11-12 16:08:48 <abrkn> what does an accoun tor a label signify in bitcoind? a collection of addresses?
210 2012-11-12 16:25:36 <kinlo> abrkn: basicly that yes...
211 2012-11-12 16:33:05 <abrkn> kinlo: im trying to keep track of the balance of users of my service and im struggling to come up with a way to track it
212 2012-11-12 16:33:38 <abrkn> use getaccountaddress and track getreceivedbyaddress for deposits (+listen using blockchain.info websockets)
213 2012-11-12 16:34:15 <abrkn> and for withdraw ensure that getaccountbalance has enough money (in some kind of mutex)
214 2012-11-12 16:34:23 <abrkn> *head spins*
215 2012-11-12 16:34:52 <abrkn> or just drop getaccountbalance and use my own apps balance tracking
216 2012-11-12 16:55:18 <kinlo> abrkn: I use my own tracking...
217 2012-11-12 16:55:35 <kinlo> abrkn: you need hot and cold wallets, so your bitcoind is out of sync anyway
218 2012-11-12 16:55:42 <abrkn> kinlo: how custom is it? do you analyze every block?
219 2012-11-12 16:56:05 <kinlo> as I am a pool, I track completly differently
220 2012-11-12 16:56:18 <kinlo> but remember, you will use hot and cold wallets...
221 2012-11-12 16:56:29 <kinlo> so your coins won't even be on the server
222 2012-11-12 16:56:31 <kinlo> anyway afk
223 2012-11-12 17:48:08 <doublec> abrkn: I track account balances and similar within the app rather than using the bitcoind accounts functionality
224 2012-11-12 17:48:22 <doublec> abrkn: like kinlo mentioned it makes dealing with multiple wallets a bit easier
225 2012-11-12 17:48:40 <doublec> abrkn: if you ever need to move to a new wallet it's a pain with accounts
226 2012-11-12 19:55:35 <MC-Eeepc> wow there are over 10,000 pending txns
227 2012-11-12 19:55:44 <MC-Eeepc> anyone notice that keeps getting wrose
228 2012-11-12 19:56:06 <MC-Eeepc> make that 15,000
229 2012-11-12 19:56:37 <MC-Eeepc> do people need to start paying fees or what
230 2012-11-12 19:57:11 <jeremias> yep
231 2012-11-12 19:57:17 <jeremias> how is that a problem?
232 2012-11-12 19:57:56 <jeremias> or do you consider that a problem?
233 2012-11-12 20:00:08 <MC-Eeepc> its a problem if it keeps increasing rite
234 2012-11-12 20:00:17 <MC-Eeepc> used to be under 1000
235 2012-11-12 20:02:45 <jeremias> well, the fees are not near any meaningful factor to me
236 2012-11-12 20:02:59 <jeremias> if they keep to be under few cents, that is fine to me
237 2012-11-12 20:03:18 <jeremias> and then you can start to optimize
238 2012-11-12 20:07:09 <MC-Eeepc> 15,000 pending txn and the last block only cleared 369 of them
239 2012-11-12 20:10:14 <Luke-Jr> MC-Eeepc: most of them are spam
240 2012-11-12 20:10:42 <MC-Eeepc> define spam
241 2012-11-12 20:12:17 <Cusipzzz> satoshi dice double spends and no fee freeloaders
242 2012-11-12 20:12:44 <sipa> why would you try doublespending SD? :o
243 2012-11-12 20:12:53 <MC-Eeepc> you cant double spend SD
244 2012-11-12 20:13:09 <sipa> my point exactly
245 2012-11-12 20:13:20 <Cusipzzz> no, their payments are respending the same input, so they have to wait
246 2012-11-12 20:13:28 <Cusipzzz> hence a lot of pending txns
247 2012-11-12 20:13:42 <sipa> ?
248 2012-11-12 20:13:54 <yellowhat> is grau the author of bitsofproof here somewhere?
249 2012-11-12 20:13:56 <Cusipzzz> they have to wait for the wager txn to confirm
250 2012-11-12 20:14:03 <sipa> Cusipzzz: no
251 2012-11-12 20:14:24 <sipa> they can be included in the same block
252 2012-11-12 20:14:27 <Cusipzzz> sipa: oh? never seen an sd payment confirm without the wager payment
253 2012-11-12 20:14:27 <MC-Eeepc> !seen genjix
254 2012-11-12 20:14:28 <gribble> genjix was last seen in #bitcoin-dev 11 weeks, 0 days, 18 hours, 44 minutes, and 7 seconds ago: <genjix> https://www.youtube.com/watch?v=zh8W4ZglOlw
255 2012-11-12 20:14:42 <Cusipzzz> right, same block, but still a lot of pending txns
256 2012-11-12 20:15:15 <sipa> their payout mechanism just results in a massive amount of transactions
257 2012-11-12 20:15:26 <MC-Eeepc> so its just the priority system doing its job?
258 2012-11-12 20:15:28 <Luke-Jr> MC-Eeepc: you sure can
259 2012-11-12 20:15:41 <Luke-Jr> sipa: doublespending SD is quite profitable :P
260 2012-11-12 20:15:52 <sipa> ?
261 2012-11-12 20:16:09 <Luke-Jr> sipa: if you lose, you get the doublespend mined; if you win, you don't
262 2012-11-12 20:16:19 <sipa> ha, of course
263 2012-11-12 20:16:20 <Cusipzzz> bet max, isolate them, if wager=loss doublespend to rest of network
264 2012-11-12 20:16:33 <Cusipzzz> or just the large pools :)
265 2012-11-12 20:17:19 <Luke-Jr> moreover, this helps defeat the DDoS
266 2012-11-12 20:17:29 <Luke-Jr> since SD uses the outputs from losses to cover the wins
267 2012-11-12 20:17:46 <Luke-Jr> someone should streamline it :D
268 2012-11-12 20:18:01 <Cusipzzz> easier would be for miners to reject SD txns, unless the fee is .01+
269 2012-11-12 20:18:49 <Luke-Jr> Cusipzzz: a number of miners reject SD txns period.
270 2012-11-12 20:19:04 <Cusipzzz> Luke-Jr: good
271 2012-11-12 20:19:56 <Luke-Jr> I wouldn't mind accepting them with 1+ BTC fees, but no point writing code nobody will ever use
272 2012-11-12 20:21:28 <Cusipzzz> get a few big pools on board and it will force them to use accounts rather than this spam
273 2012-11-12 20:23:06 <Luke-Jr> hah
274 2012-11-12 20:23:23 <Luke-Jr> we can't even get most of the bigger pools to care about decentralized mining
275 2012-11-12 20:24:56 <Cusipzzz> well, we wouldn't want big pools agreeing on anything usually, but this one would be ok
276 2012-11-12 20:31:48 <wizkid057> still worrying about satoshidice? heh
277 2012-11-12 20:34:00 <wizkid057> i dont like the concept at all, and it seems to abuse the network, but.... at the same time it doesnt make bitcoin look very useful.  If one entitiy with a relatively decent amount of transaction volume can cause disruption to the network... then theres an issue with scalability.  Bitcoin is going to need to be able to handle many thousands of times more tranactions per time period than
278 2012-11-12 20:34:01 <wizkid057> it does now, even with SD, if it is to be useful in the longterm, and right now it isnt.
279 2012-11-12 20:34:59 <wizkid057> there are many road blocks to mass adoption
280 2012-11-12 20:35:35 <wizkid057> this is one, the fact that its taking a beast of a server of mine > 2 days to download/process the blockchain is another, etc
281 2012-11-12 20:36:28 <yellowhat> it would be interesting to hear the opinion of you guys on this project idea:
282 2012-11-12 20:36:29 <yellowhat> https://github.com/bitcoinaustria/bitnotar
283 2012-11-12 20:37:01 <yellowhat> we implemented a bitcoin-based document timestamp service in a few hours at a local hackathon.
284 2012-11-12 20:37:08 <Luke-Jr> wizkid057: you're not running git master on that server tho
285 2012-11-12 20:37:27 <yellowhat> do you see any possible obvious flaws in the idea or is it viable?
286 2012-11-12 20:37:49 <wizkid057> Luke-Jr: there some improvement between the tarbar on bitcoin.org and git master?
287 2012-11-12 20:37:51 <yellowhat> the presentation we did at the end is here: https://docs.google.com/presentation/pub?id=1qS8zFR5TLxRtVAV6qzBOTHMy4_wlWh69t_FQMTmpg48&start=false&loop=false&delayms=3000
288 2012-11-12 20:38:14 <Luke-Jr> wizkid057: significant
289 2012-11-12 20:38:34 <wizkid057> hmm
290 2012-11-12 20:38:41 <Luke-Jr> wizkid057: bdb is almost gone now (just wallet)
291 2012-11-12 20:38:44 <jrmithdobbs> wizkid057: a beast? really? until i updated past .7 my p4 (prescott) with slow as fuck disks in software raid running in 32bit mode did a IBD in <24 hours ...
292 2012-11-12 20:38:59 <jrmithdobbs> something's wrong with your box
293 2012-11-12 20:39:11 <sipa> not necessarily
294 2012-11-12 20:39:12 <Luke-Jr> jrmithdobbs: well, the IBD code sucks too
295 2012-11-12 20:39:18 <sipa> indeed
296 2012-11-12 20:39:23 <wizkid057> jrmithdobbs: its an Amazon EC2 high CPU instance
297 2012-11-12 20:39:29 <sipa> oh that explains
298 2012-11-12 20:39:32 <Luke-Jr> could just as well be bad luck on peer selection and network activity
299 2012-11-12 20:39:32 <sipa> very slow I/O
300 2012-11-12 20:39:36 <wizkid057> nope, blockchain is in RAM
301 2012-11-12 20:39:38 <jrmithdobbs> so ya, something's wrong with your box
302 2012-11-12 20:39:38 <wizkid057> and index
303 2012-11-12 20:39:40 <jrmithdobbs> (you have shit i/o)
304 2012-11-12 20:39:43 <wizkid057> on tmpfs
305 2012-11-12 20:39:45 <sipa> oh
306 2012-11-12 20:39:50 <sipa> ok, bad IBD then
307 2012-11-12 20:40:13 <jrmithdobbs> ya, only explanation for that is bad dice rolls when choosing the peer you're downloading from
308 2012-11-12 20:40:21 <wizkid057> well
309 2012-11-12 20:40:28 <wizkid057> i hacked source to allow more outbounds
310 2012-11-12 20:40:36 <wizkid057> but it was slow before that also
311 2012-11-12 20:40:37 <Luke-Jr> wizkid057: bad idea :
312 2012-11-12 20:40:38 <sipa> doesn't help a thing
313 2012-11-12 20:40:39 <jrmithdobbs> wont matter
314 2012-11-12 20:40:46 <sipa> at least from disk, it takes 2.5 hours on my VPS to reindex the entire chain
315 2012-11-12 20:40:48 <wizkid057> i know
316 2012-11-12 20:40:52 <Luke-Jr> wizkid057: more connections = less time spent on IBS
317 2012-11-12 20:40:53 <Luke-Jr> IBD*
318 2012-11-12 20:41:04 <sipa> most of which is signature verification after 192k
319 2012-11-12 20:41:09 <jrmithdobbs> and only one peer is used for the IBD at a time any ways
320 2012-11-12 20:41:23 <wizkid057> i'll try a roll up of git master
321 2012-11-12 20:41:25 <wizkid057> and see how it goes
322 2012-11-12 20:41:36 <Luke-Jr> wizkid057: just note git master isn't presumed stable for mining yet
323 2012-11-12 20:41:45 <jrmithdobbs> wizkid057: -nolisten -addpeer=<known good node> is best way to work around that
324 2012-11-12 20:41:52 <wizkid057> be fine for a random well-connected node, though
325 2012-11-12 20:41:56 <Luke-Jr> jrmithdobbs: or just -connect
326 2012-11-12 20:42:03 <jrmithdobbs> ya
327 2012-11-12 20:42:12 <wizkid057> doesnt -loadblocks work?
328 2012-11-12 20:42:16 <Luke-Jr> & or that
329 2012-11-12 20:42:42 <wizkid057> i'll mess with it later
330 2012-11-12 20:43:10 <sipa> with current git head you can even just copy your old blk000{1,2}.dat to blocks/blk0000{0,1}.dat, and start with -reindex
331 2012-11-12 20:43:19 <sipa> to import them "in place"
332 2012-11-12 20:43:25 <wizkid057> ah
333 2012-11-12 20:44:10 <wizkid057> if I know my blk*.dat files are legit, any way I can tell bitcoin to not bother verifying anything about them?
334 2012-11-12 20:44:20 <wizkid057> i notice -loadblocks still does full verification
335 2012-11-12 20:44:22 <Luke-Jr> wizkid057: it still has to make the index
336 2012-11-12 20:44:36 <sipa> verification is not the problem, maintaining the indx is
337 2012-11-12 20:44:42 <Luke-Jr> wizkid057: when master is done, it uses like 80 MB db only
338 2012-11-12 20:44:52 <sipa> 120 MB these days
339 2012-11-12 20:44:55 <Luke-Jr> meh
340 2012-11-12 20:45:09 <sipa> well, after 193k, the significant part becomes signature verification
341 2012-11-12 20:45:51 <wizkid057> thats what i'm saying
342 2012-11-12 20:45:56 <wizkid057> useless dice txn verifications
343 2012-11-12 20:46:40 <sipa> there should be a way to prevent redoing all verification when importing an old chain yes
344 2012-11-12 20:46:49 <wizkid057> SD should make an alt chain, and run an exchange
345 2012-11-12 20:46:50 <wizkid057> lol
346 2012-11-12 20:46:58 <jrmithdobbs> SD should just die
347 2012-11-12 20:47:06 <wizkid057> that'd be too easy
348 2012-11-12 20:47:15 <sipa> but the re-verification has some nice benefits (given the number of stuck nodes, i assume there are many corrupted chains already)
349 2012-11-12 20:47:18 <wizkid057> but like I said, if SD causes this much hassle, then bitcoin has issues
350 2012-11-12 20:47:43 <gmaxwell> wizkid057: whats the hassle?
351 2012-11-12 20:48:27 <wizkid057> blocks made post-SD take ages to verify, blocks bloated with useless transactions, legit transactions taking way longer than the system intends to confirm, etc
352 2012-11-12 20:49:04 <wizkid057> SD bloated block orphan risk for miners
353 2012-11-12 20:49:15 <wizkid057> i'm sure i'm missing some hassles here
354 2012-11-12 20:49:17 <sipa> define 'ages'
355 2012-11-12 20:49:23 <Luke-Jr> wizkid057: to be fair, SD load is far more than any existing payment network handles
356 2012-11-12 20:49:30 <Luke-Jr> proportionally speaking
357 2012-11-12 20:49:38 <wizkid057> ?
358 2012-11-12 20:49:50 <sipa> on my laptop, with git head code, on a single core, i can do 2-3 blocks/s
359 2012-11-12 20:49:55 <wizkid057> proportionally? my local walmart does more txns per day than SD
360 2012-11-12 20:49:57 <wizkid057> lol
361 2012-11-12 20:50:29 <sipa> after 193k, that is
362 2012-11-12 20:50:32 <Luke-Jr> wizkid057: for far more people
363 2012-11-12 20:50:57 <Luke-Jr> wizkid057: imagine if everyone who went into your walmart did like 20 tiny transactions
364 2012-11-12 20:51:00 <Luke-Jr> on average
365 2012-11-12 20:51:19 <Luke-Jr> every day.
366 2012-11-12 20:51:27 <wizkid057> thats an interesting way to put it
367 2012-11-12 20:51:38 <Luke-Jr> I bet every WalMart doing that would kill VISA even
368 2012-11-12 20:51:39 <wizkid057> but, physical retail is different than electronic
369 2012-11-12 20:51:54 <wizkid057> lol, you'd be surprised how robust VISA is
370 2012-11-12 20:52:27 <wizkid057> people have tried "DDoS'ing" VISA with transactions... all it did was delay authorizations coming in by a couple of seconds
371 2012-11-12 20:52:39 <Cusipzzz> VISA would shut down any merchant that did what SD does.. or kill them with fees
372 2012-11-12 20:52:46 <Luke-Jr> probably
373 2012-11-12 20:53:01 <wizkid057> Cusipzzz: true, but, there are micro transaction contracts
374 2012-11-12 20:53:10 <midnightmagic> wizkid057: Who DDoS'd visa with txn?
375 2012-11-12 20:53:14 <gmaxwell> I've caused my brokerage to call me and ask me to make fewer ACHs.
376 2012-11-12 20:53:15 <jrmithdobbs> wizkid057: ya the fact that bitcoin hasn't completely imploded due to satoshi's dice shit design is actually a testament to how well it does work
377 2012-11-12 20:53:33 <jrmithdobbs> err satoshi dice's shit design
378 2012-11-12 20:53:47 <wizkid057> dont get me wrong, bitcoin is doing OK with it
379 2012-11-12 20:53:56 <wizkid057> but what if 5 more SD-like entities pop up?
380 2012-11-12 20:54:21 <jrmithdobbs> wizkid057: the SD guy has been asked to change how things work to play nicer and get the same results he does now, he's just a dick and is like "nope deal with it"
381 2012-11-12 20:54:24 <gmaxwell> wizkid057: what if?
382 2012-11-12 20:54:24 <jrmithdobbs> (if you weren't aware)
383 2012-11-12 20:54:42 <wizkid057> gmaxwell: more like when
384 2012-11-12 20:54:46 <gmaxwell> wizkid057: it can't make bitcoin any slower.
385 2012-11-12 20:54:47 <midnightmagic> wizkid057: it won't matter; the capacity for it is X, the suppliers don't matter.
386 2012-11-12 20:55:04 <midnightmagic> wizkid057: And in fact, others have already tried it and as far as I know that was the last we all heard of them.
387 2012-11-12 20:55:04 <wizkid057> not actual gambling things like SD
388 2012-11-12 20:55:07 <gmaxwell> wizkid057: it's already happened there are many unsccessful clones.
389 2012-11-12 20:55:11 <wizkid057> i mean entities with the volume of SD
390 2012-11-12 20:55:18 <wizkid057> not clones
391 2012-11-12 20:55:27 <jrmithdobbs> wizkid057: well, like luke mentioned, SD does more txns/day than visa net right now
392 2012-11-12 20:55:31 <jrmithdobbs> so that's pretty unlilkely
393 2012-11-12 20:55:41 <sipa> heh?
394 2012-11-12 20:55:44 <wizkid057> SD does not do more txns per day than visa....
395 2012-11-12 20:55:52 <wizkid057> lets clear that up now
396 2012-11-12 20:55:53 <wizkid057> lol
397 2012-11-12 20:56:11 <midnightmagic> wizkid057: The reward would need to be gambling-like and potentially large, or else people wouldn't DoS themselves.
398 2012-11-12 20:56:44 <wizkid057> midnightmagic: what if a company like Amazon.com decided they wanted to accept bitcoins?
399 2012-11-12 20:56:51 <jrmithdobbs> wizkid057: but they do due to their bad code?
400 2012-11-12 20:57:00 <jrmithdobbs> wizkid057: it'd handle it fine.
401 2012-11-12 20:57:17 <wizkid057> you're very optimistic ;)
402 2012-11-12 20:57:22 <midnightmagic> wizkid057: That would be fine, the amounts flowing would be large and not dust-like.
403 2012-11-12 20:57:34 <midnightmagic> wizkid057: The mines would be falling all over themselves to collect the fees.
404 2012-11-12 20:57:34 <wizkid057> i dont think the amounts matter
405 2012-11-12 20:57:58 <midnightmagic> The amounts do matter. If SD was purely largescale nobody would be bitching about it.
406 2012-11-12 20:58:02 <jrmithdobbs> wizkid057: SD really does more txns/day (not user-facing txns necessarily, but on the blockchain) than visa net, that's not an exageration :(
407 2012-11-12 20:58:04 <wizkid057> a txn that moves 1 satoshi can take up as much blockchain space as a txn that moves 100000 BTC
408 2012-11-12 20:58:25 <wizkid057> jrmithdobbs: how many txns per day do you think visa does?
409 2012-11-12 20:58:45 <midnightmagic> yes, but the fees would be greater, txn velocity would be greater, as a whole bitcoin would win.
410 2012-11-12 20:58:47 <gmaxwell> visa does zero bitcoin transactions per day. :P
411 2012-11-12 20:59:06 <gmaxwell> but wtf did you get this idea of visa a point of reference. Thats bonkers.
412 2012-11-12 20:59:07 <jrmithdobbs> VisaNet authorizes, clears and settles an average of 130 million transactions per day in 200 countries and territories.
413 2012-11-12 20:59:07 <wizkid057> bitcoin's best day was somewhere near 60k transactions I think
414 2012-11-12 20:59:14 <gmaxwell> wizkid057: what exactly are you going on about in any case?
415 2012-11-12 20:59:30 <wizkid057> gmaxwell: they're trying to tell me bitcoin can handle Visa's volume... lol
416 2012-11-12 20:59:48 <midnightmagic> wizkid057: Amazon also represents actual economic activity of physical-space goods, which would drive demand higher for bitcoin. i'm pretty sure people don't buy bitcoin just to gamble with sd.
417 2012-11-12 21:00:04 <gmaxwell> wizkid057: Why are you concerned that bitcoin is currently only 1000x realtime at its maximum volume?
418 2012-11-12 21:00:06 <midnightmagic> wizkid057: That's Luke-Jr saying that BTW.
419 2012-11-12 21:00:48 <wizkid057> midnightmagic: i wasn't refering to the added benefits of amazon being on board, i was refering to the network in general not being crippled under the volume
420 2012-11-12 21:01:19 <gmaxwell> wizkid057: Are you ignoring me because I'm trying to make you clarify what you mean with bullshit fud like "crippled under the volume"?
421 2012-11-12 21:01:19 <wizkid057> gmaxwell: i dont understand that statement...
422 2012-11-12 21:01:40 <midnightmagic> wizkid057: Well, you can speak in a hypothetical, but you'll have to describe an actual problematic hypothetical or else it's just imaginary right?
423 2012-11-12 21:01:41 <wizkid057> crippled under the volume? how is that not clear... heh
424 2012-11-12 21:01:47 <gmaxwell> wizkid057: the current software can validate the chain at something like 1000x realtime.
425 2012-11-12 21:02:19 <gmaxwell> wizkid057: stop trolling and go test current code. :P
426 2012-11-12 21:02:27 <wizkid057> everyone isnt running current code
427 2012-11-12 21:02:47 <wizkid057> hell, even the bitcoin website doesnt provide this current code :P
428 2012-11-12 21:02:50 <midnightmagic> people who buckle becaue theyre runing old code will upgrade.
429 2012-11-12 21:02:52 <gmaxwell> Yes sure. But only you going and testing the current stuff can solve that. :P
430 2012-11-12 21:04:18 <wizkid057> well, in any case
431 2012-11-12 21:04:38 <wizkid057> whats the theoretical maximum txns per day bitcoin can currently handle?
432 2012-11-12 21:04:40 <jrmithdobbs> gmaxwell: is the bloomfilter stuff going to make .8 or is that decided yet?
433 2012-11-12 21:04:49 <sipa> jrmithdobbs: i hope it will
434 2012-11-12 21:04:53 <Cusipzzz> sd is a plague because the spam is not needed. the network handles it fine.
435 2012-11-12 21:04:55 <sipa> (and i'm not alone)
436 2012-11-12 21:04:57 <wizkid057> assuming all perfect tiny transactions
437 2012-11-12 21:05:07 <jrmithdobbs> sipa: i do too, just wondering how practical that hope is :P
438 2012-11-12 21:05:10 <gmaxwell> wizkid057: on the order of a half million or so. (somewhat more if you really talk about the smallest possible)
439 2012-11-12 21:05:29 <wizkid057> ok, so a long ways off from Visa :)
440 2012-11-12 21:05:41 <Cusipzzz> Visa pays better :p
441 2012-11-12 21:05:45 <wizkid057> that too
442 2012-11-12 21:05:46 <wizkid057> :P
443 2012-11-12 21:05:54 <gmaxwell> wizkid057: bitcoin is almost but not quite entirely unlike visa.
444 2012-11-12 21:06:07 <gmaxwell> (they are similar in that they transfer value between parties!)
445 2012-11-12 21:06:14 <jrmithdobbs> wizkid057: also it's semi-arbitrary since that's based on the current blocksize limit that can be changed
446 2012-11-12 21:06:18 <sipa> bitcoin is a currency; it is not a payment system
447 2012-11-12 21:06:24 <gmaxwell> jrmithdobbs: s/can/can't/
448 2012-11-12 21:06:25 <wizkid057> its both
449 2012-11-12 21:06:33 <jrmithdobbs> gmaxwell: why can't it?
450 2012-11-12 21:06:41 <wizkid057> what good is a currency without a payment system of some kind? hehe
451 2012-11-12 21:06:45 <gmaxwell> jrmithdobbs: unless you want to say 21 million sum total btc can be changed it's exactly the same technical effort to change either.
452 2012-11-12 21:07:00 <sipa> wizkid057: it provides payments of the style of giving someone cash, in the digital world
453 2012-11-12 21:07:02 <jrmithdobbs> gmaxwell: the 1M blocksize limit?
454 2012-11-12 21:07:18 <gmaxwell> wizkid057: it's a currency with a limited payment system, enough to make it usable. It's not a retail payment network and fundimentally can't be a good one.
455 2012-11-12 21:07:19 <wizkid057> sipa: physical cash is a payment system
456 2012-11-12 21:07:23 <sipa> agree, it is
457 2012-11-12 21:07:34 <sipa> but it's a very rudimentary one
458 2012-11-12 21:08:02 <wizkid057> gmaxwell: if it cant be a good one, how am I ever going to buy stuff at walmart with bitcoins?!
459 2012-11-12 21:08:09 <gmaxwell> wizkid057: using VISA!
460 2012-11-12 21:08:11 <jrmithdobbs> you probably wont
461 2012-11-12 21:08:16 <wizkid057> lol
462 2012-11-12 21:08:34 <jrmithdobbs> wizkid057: the 10 min inclusion time makes POS use pretty unlikely at any scale, ever
463 2012-11-12 21:08:42 <sipa> why would you want that? use bitcoin where it shines: international/digital transactions
464 2012-11-12 21:08:44 <wizkid057> that'd be interesting, if Visa starting allowing BTC currency exchanges
465 2012-11-12 21:08:53 <gmaxwell> Currency and payment network are not one in the same. We want very different things from a payment system, than we do from a currency.
466 2012-11-12 21:09:12 <sipa> jrmithdobbs: disagree completely
467 2012-11-12 21:09:19 <gmaxwell> wizkid057: even withtout the currency exchange visa works in multiple currencies you know.  there is no technical reason why bitcoin couldn't just be one of them.
468 2012-11-12 21:09:36 <wizkid057> jrmithdobbs: sipa: i happen to agree, heh
469 2012-11-12 21:09:40 <jrmithdobbs> sipa: ?
470 2012-11-12 21:09:48 <gmaxwell> (and if visa is too corporate for you, invoke ripple or open transactions or whatever)
471 2012-11-12 21:10:05 <wizkid057> gmaxwell: thats what I mean (about the multiple currencies)
472 2012-11-12 21:10:25 <sipa> jrmithdobbs: a merchant doesn't wait for confirmations (weeks? months?) for accepting your credit card payment
473 2012-11-12 21:10:37 <midnightmagic> huh. i didn't realise that amd cards don't come with error-correcting memory as an option. is this so?
474 2012-11-12 21:10:50 <sipa> and neither should you in bitcoin (as long as you are aware of the risks, and probably insured against them)
475 2012-11-12 21:11:06 <wizkid057> bitcoin reminds me of the ubiquitous "credit" in a lot of future-based scifi movies and books and such
476 2012-11-12 21:11:14 <jrmithdobbs> sipa: well ya, there's an intermediary that pre-auths (in most cases if the power's on anyways) and takes the majority of the risk
477 2012-11-12 21:11:30 <sipa> exactly
478 2012-11-12 21:11:42 <sipa> bitcoin is for clearing transactions where trust doesn't exist
479 2012-11-12 21:11:55 <jrmithdobbs> sipa: i meant it wont be used *directly* at POS most likely
480 2012-11-12 21:11:57 <gmaxwell> sipa: there is, of course, different degrees of confidence.  Credit cards are reversable for months, but still less reversable than bitcoins are in the first 30 seconds.  Most merchants (but not all) do wait for an ACK from the credit processor.
481 2012-11-12 21:12:08 <sipa> sure
482 2012-11-12 21:12:15 <sipa> it's not entirely comparable
483 2012-11-12 21:12:23 <gmaxwell> I dunno the answers for that, we'll just see what people do.
484 2012-11-12 21:12:44 <Cusipzzz> people will eventually take 0conf txns for < 50$ or so, if there is demand
485 2012-11-12 21:12:48 <gmaxwell> I expect that for small value in person stuff they would just photocopy your ID and move on with life.
486 2012-11-12 21:14:18 <Cusipzzz> wizkid057: they will make enough money on the rest not to worry
487 2012-11-12 21:14:26 <wizkid057> pfft
488 2012-11-12 21:14:36 <Luke-Jr> wizkid057: no, I'm trying to say that we have no metric to compare VISA and Bitcoin :p
489 2012-11-12 21:14:41 <wizkid057> i wonder how many visa chargebacks starbucks gets...
490 2012-11-12 21:14:54 <Cusipzzz> or use a bit-pay or equivalent to detect doublespends and will take the risk
491 2012-11-12 21:15:06 <Luke-Jr> because by the time Bitcoin has the same number of legit transactions as VISA, a lot will have changed in terms of adoption
492 2012-11-12 21:15:25 <helo> bitcoin being feasible for small valued purchases is a temporary thing
493 2012-11-12 21:15:34 <sipa> if that ever happens, i doubt you and i will be running a full node
494 2012-11-12 21:15:48 <wizkid057> should definitely hard fork and change the block header size, btw
495 2012-11-12 21:15:58 <Luke-Jr> &
496 2012-11-12 21:16:06 <wizkid057> yay for ASICs :P
497 2012-11-12 21:16:09 <sipa> the block *header* size?
498 2012-11-12 21:16:11 <sipa> wtf?
499 2012-11-12 21:16:23 <helo> block space competition will raise fees, raising the minimum amount bitcoin is useful for
500 2012-11-12 21:16:55 <wizkid057> well, it'd be fun to effectively kill ASIC mining
501 2012-11-12 21:17:25 <Cusipzzz> helo: good. micro transactions spammed are not viable. but a service provider can aggregate them, like via an account at SD, and use the chain only when needed
502 2012-11-12 21:17:26 <helo> i think it's safe to assume all bitcoin users will wait the full 6 confirms, and target that use case
503 2012-11-12 21:17:37 <wizkid057> if it even exists that is
504 2012-11-12 21:17:43 <sipa> wizkid057: i'll make sure i'm on some exotic island with a fake identity before I propose that
505 2012-11-12 21:17:53 <wizkid057> lol
506 2012-11-12 21:17:55 <sipa> wizkid057: don't want the ASIC industry's secret agents behind me
507 2012-11-12 21:18:32 <helo> Cusipzzz: it'd be great to get paid in bitcoin, and cash out to local currency for short-term purchases
508 2012-11-12 21:18:32 <wizkid057> would be interesting if some bug was found which required a fix like that
509 2012-11-12 21:18:45 <Cusipzzz> 6 confirms is flat earth voodoo...tired of hearing that. it should always be discussed as a scale
510 2012-11-12 21:18:45 <Luke-Jr> wizkid057: it'd kill Bitcoi
511 2012-11-12 21:18:45 <wizkid057> i'd laugh ;P
512 2012-11-12 21:18:46 <Luke-Jr> n
513 2012-11-12 21:18:46 <sipa> ;;bc,blocks
514 2012-11-12 21:18:47 <gribble> 207673
515 2012-11-12 21:19:02 <Cusipzzz> ;;halfreward
516 2012-11-12 21:19:04 <gribble> Estimated time of bitcoin block reward halving: Thu Nov 29 02:09:04 2012 UTC | Time remaining: 2 weeks, 2 days, 3 hours, 50 minutes, and 0 seconds.
517 2012-11-12 21:19:24 <wizkid057> Luke-Jr: why?
518 2012-11-12 21:19:45 <wizkid057> because people don't know the risks in spending ooodles of money on specicialized hardware? heh
519 2012-11-12 21:20:02 <helo> 6 confirms is kind of an arbitrary level of confidence, but somewhat on the same level as 256-bit keys... it's effective
520 2012-11-12 21:20:25 <helo> wizkid057: botnet mining could >50% without asic/gpu mining
521 2012-11-12 21:20:32 <helo> particularly after asic has been ramped up
522 2012-11-12 21:20:35 <Cusipzzz> arbitrary indeed.
523 2012-11-12 21:20:49 <Luke-Jr> wizkid057: becasue Bitcoin depends on ASICs to secure it at this point
524 2012-11-12 21:21:57 <wizkid057> Luke-Jr: there are zero ASICs online
525 2012-11-12 21:22:02 <wizkid057> you're saying bitcoin is insecure?
526 2012-11-12 21:22:19 <Luke-Jr> wizkid057: there are 50 BTC subsidies
527 2012-11-12 21:22:28 <wizkid057> apples/oranges
528 2012-11-12 21:22:46 <sipa> both fruits!
529 2012-11-12 21:22:47 <Luke-Jr> wizkid057: we'll see in 2 weeks
530 2012-11-12 21:23:07 <wizkid057> there wont be an ASIC in a consumer hand in 2 weeks
531 2012-11-12 21:23:10 <wizkid057> so, i guess we will
532 2012-11-12 21:23:11 <wizkid057> hehe
533 2012-11-12 21:23:12 <Luke-Jr> I'm betting the GPUs going offline are going to bring Bitcoin to a near halt until ASICs arrive
534 2012-11-12 21:23:26 <Cusipzzz> cool, will bring back my CPU miners
535 2012-11-12 21:23:31 <Luke-Jr> &
536 2012-11-12 21:23:51 <wizkid057> if the amount of people mindlessly mining Eligius when it's down is any indication on how much people pay attention/care
537 2012-11-12 21:23:59 <wizkid057> i doubt we'll see a huge effect in 2 weeks
538 2012-11-12 21:24:10 <Luke-Jr> wizkid057: you're assuming they don't have automatic failover in place
539 2012-11-12 21:24:38 <sipa> very interesting that perhaps the introduction of asics and the subsidy halving coincide
540 2012-11-12 21:24:39 <wizkid057> i am, because a lot of the mining software (user agent) doesnt support it
541 2012-11-12 21:24:42 <sturles> How much is GPU and how much is FPGA nowadays?
542 2012-11-12 21:24:45 <Cusipzzz> people will not suddenly turn off gpu miners at block 210k, doesn't work that way. sure it may be slower til the next change, but meh
543 2012-11-12 21:25:10 <sipa> sturles: no idea
544 2012-11-12 21:25:15 <sipa> does anyone have a guess about that?
545 2012-11-12 21:25:30 <wizkid057> i predict, assuming no ASICs, that the difficulty will gradually drop
546 2012-11-12 21:25:44 <wizkid057> maybe 12 minute blocks instead of 10 for a while
547 2012-11-12 21:25:48 <Cusipzzz> very little fpga, mostly gpu currently
548 2012-11-12 21:26:16 <wizkid057> like, i have no financial reason to turn off my GPUs
549 2012-11-12 21:26:27 <wizkid057> and i'm sure many others are in similar boats
550 2012-11-12 21:26:35 <sturles> I am not going to swith my GPUs off.  I may be mining at a loss measured in kWh/BTC, but I need the heat.  It is still making more than a dumb resistor.
551 2012-11-12 21:26:38 <sipa> i have no financial reason to turn off my FPGAs :p
552 2012-11-12 21:27:00 <sipa> sturles: would you heat using electricity otherwise?
553 2012-11-12 21:27:05 <sturles> Yes.
554 2012-11-12 21:27:12 <sturles> Electricity is cheap.
555 2012-11-12 21:27:17 <sturles> Hydro power.
556 2012-11-12 21:27:20 <sipa> ha
557 2012-11-12 21:27:26 <Cusipzzz> lucky
558 2012-11-12 21:27:47 <sipa> well, where i'm from, electricity costs around $0.3/kWh (coverted)
559 2012-11-12 21:27:53 <wizkid057> ouch
560 2012-11-12 21:28:04 <wizkid057> its about $0.16-18 here
561 2012-11-12 21:28:07 <sipa> ok, rather 0.25
562 2012-11-12 21:28:16 <wizkid057> but, free for me :D
563 2012-11-12 21:28:45 <wizkid057> i'm surprised they didnt try to modify that portion of my lease when i renewed
564 2012-11-12 21:29:42 <gmaxwell> <tinfoilhat>because the've been mining on the asic's for months and are only giving them to people at the halving</tinfoilhat>
565 2012-11-12 21:29:52 <wizkid057> i need to find an efficient way to bottle up my kWh's and feed them into the grid at my parent's house or something
566 2012-11-12 21:29:57 <wizkid057> make a few bucks
567 2012-11-12 21:29:58 <wizkid057> :P
568 2012-11-12 21:30:25 <sturles> wizkid057: Buy a giant UPS! :-)
569 2012-11-12 21:30:26 <sipa> gmaxwell: haha, nice one!
570 2012-11-12 21:30:53 <Cusipzzz> gmaxwell: you give them too much credit...why give them to people..keep mining, move to costa rica, profit.
571 2012-11-12 21:30:54 <wizkid057> sturles: probably not cost effective... lol
572 2012-11-12 21:30:59 <sturles> wizkid057: Or a Tesla, and go visit them often. :-)
573 2012-11-12 21:31:19 <wizkid057> sturles: i have a Volt already, lol
574 2012-11-12 21:31:26 <sipa> 1 volt?
575 2012-11-12 21:31:27 <sturles> :-D
576 2012-11-12 21:31:36 <gmaxwell> Cusipzzz: cause it would undermine bitcoin's value if they got caught, the halving is a natural breakpoint.
577 2012-11-12 21:31:37 <wizkid057> yup, 1 Chevy Volt
578 2012-11-12 21:33:03 <Cusipzzz> gmaxwell: if bfl going under hurts bitcoin value, bitcoin should already be at 0 from the other scams
579 2012-11-12 21:33:03 <wizkid057> just so you all know, if I ever win the lottery (like, Mega Millions or something), I plan on 51% attacking bitcoin, then hiring all the devs to make something better.
580 2012-11-12 21:34:15 <sipa> wizkid057: interesting, but why do you assume that if you make something even objectively significantly better in the technical sense, people would trust it, after trust in bitcoin was lost?
581 2012-11-12 21:35:18 <wizkid057> sipa: who knows
582 2012-11-12 21:35:20 <Cusipzzz> he could escrow $100 mil, and be the 'buyer of last resort' at $5 ea for 20mil coins, would give people confidence that they won't go to 0.
583 2012-11-12 21:35:32 <wizkid057> we never will, because i'll never win the lottery
584 2012-11-12 21:35:36 <wizkid057> so, no worries
585 2012-11-12 21:35:37 <wizkid057> lol
586 2012-11-12 21:36:43 <wizkid057> but yeah, i'd spend the $10M+ needed to make and mass produce a *real* mining ASIC, get at least 2x the network's hashrate worth, and go to town
587 2012-11-12 21:37:09 <wizkid057> would be fun
588 2012-11-12 21:37:10 <wizkid057> :)
589 2012-11-12 21:37:58 <wizkid057> either that or I would do a hostile take over of satoshidice
590 2012-11-12 21:38:09 <sipa> as in: using armed forces?
591 2012-11-12 21:38:14 <wizkid057> nah
592 2012-11-12 21:38:22 <wizkid057> orphan any block that contains a SD txn
593 2012-11-12 21:38:24 <wizkid057> lol
594 2012-11-12 21:38:37 <Luke-Jr> lol
595 2012-11-12 21:59:00 <helo> how many current ~average transactions would fit in a block? 3000?
596 2012-11-12 21:59:16 <helo> roughly, of course...
597 2012-11-12 22:56:01 <MATTISBLUEBRO> Dont tase me bro
598 2012-11-12 22:58:07 <sipa> some people really just don't get "not ever gonna happen in your lifetime:
599 2012-11-12 22:58:09 <sipa> https://bitcointalk.org/index.php?topic=107172.msg1331841#msg1331841
600 2012-11-12 23:00:09 <gmaxwell> sipa: what else are people to do with their cpus now that mining on them is unprofitable????
601 2012-11-12 23:00:50 <gmaxwell> binary only where can I bet that it is actually wallet stealing malware?
602 2012-11-12 23:01:08 <sipa> gmaxwell: i don't know - what did kids use their CPUs for before Bitcoin?
603 2012-11-12 23:01:13 <sipa> seti@home?
604 2012-11-12 23:05:50 <jgarzik> Luke-Jr: eh?  Did I miss a behavior change?
605 2012-11-12 23:06:20 <jgarzik> sipa: distributed.net ;p
606 2012-11-12 23:06:53 <Luke-Jr> jgarzik: ReadHTTP no longer calls ReadHTTPStatus, so I was thanking you for renaming it to ReadHTTPMessage at the same time
607 2012-11-12 23:07:27 <phantomcircuit> sipa, some people just like to gamble
608 2012-11-12 23:07:39 <sipa> i know
609 2012-11-12 23:07:49 <Luke-Jr> jgarzik: I despise behaviour changes that don't break source-calling compatibility; they seem one of the easiest traps for bugs
610 2012-11-12 23:08:09 <sipa> phantomcircuit: but they have much better odds running oclvanitygen, or paying that address mining pool to find something
611 2012-11-12 23:08:33 <sipa> phantomcircuit: why do they use a closed-source CPU-only program that friggin hammers blockchain.info with address queries...
612 2012-11-12 23:08:37 <phantomcircuit> they have better odds just mining normally
613 2012-11-12 23:08:45 <Luke-Jr> XD
614 2012-11-12 23:08:52 <Luke-Jr> phantomcircuit: and that'd actually be legal!
615 2012-11-12 23:09:32 <phantomcircuit> we cant have that
616 2012-11-12 23:09:57 <phantomcircuit> must work very hard and spend huge amounts on electricity bills for the astronomically unlikely chance that we commit a felony
617 2012-11-12 23:10:05 <phantomcircuit> that sounds like a *much* better plan
618 2012-11-12 23:10:07 <phantomcircuit> lol idiots
619 2012-11-12 23:11:18 <gmaxwell> hm. it hammers some centeralized service? can't be all bad. :P
620 2012-11-12 23:11:40 <gmaxwell> phantomcircuit: NO! CPU MINING IS UNPROFITABLE!!!!!!!!
621 2012-11-12 23:11:53 <phantomcircuit> gmaxwell, depends on who pays for power
622 2012-11-12 23:12:18 <gmaxwell> UNPROFITABLE!!!