1 2012-06-15 00:00:58 <TuxBlackEdo> ok
  2 2012-06-15 00:01:02 <TuxBlackEdo> so [Tycho] luke-jr
  3 2012-06-15 00:01:15 <TuxBlackEdo> when am i going to be able to change my transactions
  4 2012-06-15 00:01:31 <[Tycho]> Do not want.
  5 2012-06-15 00:01:36 <TuxBlackEdo> even if 20% of the times your guy's pools finds a block
  6 2012-06-15 00:01:38 <luke-jr> TuxBlackEdo: if you're serious about paying for it, I'll do it
  7 2012-06-15 00:01:42 <TuxBlackEdo> it still gives me an advantage
  8 2012-06-15 00:01:48 <luke-jr> TuxBlackEdo: but it will require not removing outputs
  9 2012-06-15 00:01:56 <luke-jr> or decreasing them
 10 2012-06-15 00:02:05 <Matt_von_Mises> Is there supposed to be a lot of warnings when building the bitcoin tests?
 11 2012-06-15 00:02:13 <TuxBlackEdo> luke-jr, that works
 12 2012-06-15 00:03:17 <luke-jr> TuxBlackEdo: how much are you offering for me to write this? I usually charge 9-10 BTC/hr
 13 2012-06-15 00:07:04 <TuxBlackEdo> i need to think about it
 14 2012-06-15 00:07:07 <TuxBlackEdo> x_x
 15 2012-06-15 02:45:04 <gmaxwell> http://blogs.msdn.com/b/oldnewthing/archive/2012/06/14/10319617.aspx
 16 2012-06-15 02:50:11 <TuxBlackEdo> gmaxwell, is this going to be implemented in the window's version of the bitcoin client?
 17 2012-06-15 02:51:02 <gmaxwell> I'm linking to it to suggest it for consideration by people who are more familar with bitcoin on windows than I am.
 18 2012-06-15 02:51:23 <gmaxwell> (so that it can try to shut down cleanly)
 19 2012-06-15 02:55:39 <gmaxwell> luke-jr: reason to not worry much about how crappy debian's bitcoin packages are: http://qa.debian.org/popcon.php?package=bitcoin
 20 2012-06-15 02:56:31 <luke-jr> gmaxwell: 350 seems like a lot for just Debian?
 21 2012-06-15 02:56:56 <luke-jr> about 1/4 of all 0.3 nodes
 22 2012-06-15 02:57:19 <gmaxwell> Hm? it's 350 installed, 61 in active use out of like 122k.
 23 2012-06-15 02:57:36 <gmaxwell> (well active use is 61-350, as some people have atime off)
 24 2012-06-15 05:16:25 <banshee12> What is it with my transactions taking so long to be included in a block today? :(
 25 2012-06-15 05:17:43 <banshee12> Gave a way a bunch of btc but most of them are unconfirmed still...
 26 2012-06-15 06:11:45 <Geebus> I have a problem... could anyone offer insight into correct this error? http://i.imgur.com/ps3n0.png
 27 2012-06-15 06:12:19 <Geebus> I have ~15k transactions in my wallet... give or take.
 28 2012-06-15 06:13:29 <gribble> New news from bitcoinrss: Diapolo opened pull request 1469 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1469>
 29 2012-06-15 08:01:08 <Nachtwind> Hi, stupid Question... are there multiple Addresses available for a private key?
 30 2012-06-15 08:01:48 <MagicalTux> no
 31 2012-06-15 08:01:53 <MagicalTux> a private key translates to only one address
 32 2012-06-15 08:02:17 <Nachtwind> hm..
 33 2012-06-15 08:02:24 <Nachtwind> ok, then i am doing something wrong *G*
 34 2012-06-15 08:02:45 <Nachtwind> tried to add keys to bitcoinJ that i generated using vanitygen.. but i get different addresses
 35 2012-06-15 08:03:08 <MagicalTux> heh
 36 2012-06-15 08:03:36 <MagicalTux> you can try adding one on MtGox and see how it resolves, so you'll know where the issue comes from
 37 2012-06-15 08:03:51 <Nachtwind> good point
 38 2012-06-15 08:03:56 <MagicalTux> (note that if you do that, MtGox will keep it in memory and credit on your account any fund sent subsequently there)
 39 2012-06-15 08:05:32 <Nachtwind> would you mind telling me where i can add a key to mtgox? havent been on the page in ages
 40 2012-06-15 08:06:09 <Nachtwind> nvm found it
 41 2012-06-15 08:06:45 <Nachtwind> mhm.... ok
 42 2012-06-15 08:06:58 <Nachtwind> it translates right.. so i do something completely wrong in the bitcoinj part
 43 2012-06-15 08:08:02 <MagicalTux> :)
 44 2012-06-15 08:09:32 <Nachtwind> ok.. got it
 45 2012-06-15 08:09:36 <Nachtwind> thanks for the help :)
 46 2012-06-15 08:09:56 <Nachtwind> simple solution: Just dont cast something to something else and expect it to work if you dont know what you do ;)
 47 2012-06-15 08:10:42 <MagicalTux> :D
 48 2012-06-15 08:14:05 <sturles> I want to accept bitcoin payments to a web service, and notify the user as soon as coins are received.  Before any confirmations.  For security reasons I don't want a live wallet on the server.  Is there some modified bitcoind or other tool which can monitor a list of addresses on the P2P network and trig as soon as one of the addresses receive a payment?
 49 2012-06-15 08:15:08 <sturles> I want to keep the private keys on a completely separate server, which is offline except when I need the coins.
 50 2012-06-15 08:20:18 <yellowhat> i wanted to know about the new light client extensions.. does anyone know specifics about it?
 51 2012-06-15 08:20:20 <yellowhat> for example, if a lightweight client is initialized with an existing private key but no knowledge of transactions or blocks - how would this be handled?
 52 2012-06-15 08:23:02 <yellowhat> as far as i understand the existing proposals this would not work well because it would need to know about old existing transactions to generate a new one. the bloom filters could not be used to query about old transactions but only lessen the network load for new incoming tx
 53 2012-06-15 08:23:36 <sipa> yellowhat: rescanning always requures redownloading the chain
 54 2012-06-15 08:23:45 <sipa> *requires
 55 2012-06-15 08:24:39 <yellowhat> well if i am a lightweit client with only a private key (where i suspect to have some bitcoins already loaded) it would make a lot of sense to ask: give me a list of unspent outputs matching the bloom filter.
 56 2012-06-15 08:25:11 <sipa> etotheipi had a proposal that would allow that
 57 2012-06-15 08:25:30 <sipa> but in general it's something we must avoid, in my opinion
 58 2012-06-15 08:25:53 <sipa> and just generate keys on the device they are going to be used on
 59 2012-06-15 08:26:18 <yellowhat> then i can easily display a balance sign transactions and do everything i need to do and afterwards forget everything else.
 60 2012-06-15 08:26:25 <yellowhat> why do you think its a bad idea?
 61 2012-06-15 08:26:34 <sipa> it is a good idea
 62 2012-06-15 08:27:03 <yellowhat> what do you specifically mean by "we must avoid"
 63 2012-06-15 08:27:08 <sipa> but i think we should aim for frameworks in the future that do not require looking back at past transactions
 64 2012-06-15 08:27:32 <sipa> in some cases it is unavoidable, like when recovering from a backup
 65 2012-06-15 08:28:18 <yellowhat> i have a very real use case that regulary requires it
 66 2012-06-15 08:28:34 <sipa> yes, they certainly exist
 67 2012-06-15 08:28:46 <sipa> which one in particular?
 68 2012-06-15 08:30:31 <yellowhat> i'm trying to work a software stack for the bitcoincard people. there will be android/windows/linux machines acting as gateways for the ocassionally visiting bitcoincard user. he will show up and tell the device: hey here is my address, please tell me what i can spend
 69 2012-06-15 08:34:04 <yellowhat> so it will be impossible for the device to recan the blockchain. someone needs to have all outputs indexed by address such that he can use a bloom filter efficiently to query
 70 2012-06-15 08:35:17 <yellowhat> and by "someone" i mean a full node / supernode on the network - not the gateway itself
 71 2012-06-15 08:54:20 <yellowhat> sipa, do you have a link the the etotheipi proposal?
 72 2012-06-15 08:55:42 <jarpiain> yellowhat: casascius proposed address->block index in https://bitcointalk.org/index.php?topic=45864.0
 73 2012-06-15 08:56:10 <jarpiain> and I did some work on it but it's badly out of date now
 74 2012-06-15 10:58:50 <rebroad> bitcoin-qt seems to take up rather a lot of memory... >1.4Gb on my 3Gb laptop...
 75 2012-06-15 11:21:16 <gmaxwell> rebroad: I've only observed it taking a lot of memory when running a large number of concurrent connections.
 76 2012-06-15 11:25:08 <sipa> gmaxwell: saw my calculations yesterday for storage of txids + txouts?
 77 2012-06-15 11:26:10 <gmaxwell> About 84 megs sounded hard to believe!
 78 2012-06-15 11:26:38 <sipa> indeed
 79 2012-06-15 11:26:57 <sipa> but i think it's correct
 80 2012-06-15 11:27:02 <justmoon> sipa: where would one go to see those calculations? irc logs?
 81 2012-06-15 11:27:08 <sipa> justmoon: yes
 82 2012-06-15 11:27:19 <sipa> wait, let me just run it again and paste it somewher
 83 2012-06-15 11:27:21 <jgarzik> here again... what is memory?  process size includes a lot of shared library memory and other stuff mapped -- but not paged in
 84 2012-06-15 11:27:38 <jgarzik> boost and glibc add to the total "process size", simply by linking in
 85 2012-06-15 11:32:44 <sipa> gmaxwell, justmoon: http://pastebin.com/EHEZNHFY
 86 2012-06-15 11:34:42 <justmoon> what is unspent txouts vs serialized unspent txout list?
 87 2012-06-15 11:35:15 <sipa> serialized unspent txout list includes transaction hashes, and a compact representation of which outputs are already spent
 88 2012-06-15 11:35:38 <sipa> that's basically the size of all information you need to be able to do full transaction validation
 89 2012-06-15 11:35:50 <sipa> (if received from a trusted source)
 90 2012-06-15 11:38:14 <justmoon> is that 84 MB figure with compression or without?
 91 2012-06-15 11:38:18 <sipa> without
 92 2012-06-15 11:38:31 <justmoon> that's surprising indeed
 93 2012-06-15 11:39:01 <sipa> an in-memory data structure for that, which allows fast updating will easily be twice as large, though
 94 2012-06-15 11:39:10 <gmaxwell> sipa: might make sense to start implementing it as purely a caching mechenism.
 95 2012-06-15 11:39:42 <sipa> i really hope i'm correct that you don't need anything but txouts to do transaction validation
 96 2012-06-15 11:41:46 <yellowhat> what kind of data structure is used for that 84 MB figure?
 97 2012-06-15 11:42:02 <sipa> none at all; it's the size of a compact serialization
 98 2012-06-15 11:42:39 <Prattler> 100 MB blockchain! woohoo!! (party)
 99 2012-06-15 11:42:40 <yellowhat> but you are storing the output addresses? or pointers to a centralized list of addresses?
100 2012-06-15 11:43:12 <justmoon> output addresses are part of the txout, so yes those will be in there
101 2012-06-15 11:43:16 <sipa> it contains the full txouts, so yes that includes those
102 2012-06-15 11:43:27 <sipa> and no, no special tricks like using a central pool
103 2012-06-15 11:43:58 <justmoon> speaking of a central pool, can you generate those 84 MB as a file? I'd love to see what bzip does with it
104 2012-06-15 11:44:20 <justmoon> given the amount of address reuse (that matt wants to "fix") you might get some meaningful compression
105 2012-06-15 11:44:40 <sipa> the only compressible thing in it will be the txout amounts, and the repeated standard txout scripts
106 2012-06-15 11:44:54 <osxorgate> bitcoin-qt is syncing the last 100 or so blocks.. taking forever, at least half an hour and i'm at 25 more left. is my machine really that bad?
107 2012-06-15 11:44:55 <justmoon> precisely
108 2012-06-15 11:44:57 <sipa> so i guess maybe it can be reduced by megabyte or two
109 2012-06-15 11:45:03 <gmaxwell> sipa: you could do compression of public keys that aren't compressed.
110 2012-06-15 11:45:11 <sipa> gmaxwell: good point
111 2012-06-15 11:45:21 <justmoon> sipa: I wouldn't be so confident about estimating how much that will be
112 2012-06-15 11:45:22 <sipa> but at 84 MiB, i hardly care...
113 2012-06-15 11:45:58 <sipa> anyway, i'm trying to write a bitcoind that uses a database with that information for validation
114 2012-06-15 11:46:26 <sipa> you'll still need the full blocks for rescanning or reorganisations
115 2012-06-15 11:46:42 <sipa> but for many use cases, i think it'd suffice to only keep the last 1000 or so
116 2012-06-15 11:48:57 <sipa> gmaxwell: there are hardly any public keys in the txouts...
117 2012-06-15 11:52:28 <gmaxwell> hm. you could go further if you did txid,h(txout) and had a way to get peers to alwats provide the outs with the txn.
118 2012-06-15 11:52:54 <justmoon> gmaxwell: see my IMTUO proposal where I explore that option
119 2012-06-15 11:53:10 <justmoon> my conclusion was that network bandwidth may actually be more valuable than storage space
120 2012-06-15 11:54:09 <gmaxwell> I dunno, many txouts will never be spent.
121 2012-06-15 11:54:25 <justmoon> sipa: there are 1678784 txouts and most of them are standard txouts I assume, so couldn't you save 1.6m * 5 bytes = 8 MB by leaving out those standardized bytes? 0x76 0xA9 0x14 ... 0x88 0xAC
122 2012-06-15 11:55:46 <sipa> justmoon: yup
123 2012-06-15 11:56:42 <sipa> i wonder what bdb's overhead is, if i store store a map txid -> unspent_txouts in it
124 2012-06-15 11:57:41 <sipa> actually, it's almost a pity that txids are 256 bit... that's a non-negligable percentage
125 2012-06-15 11:57:56 <someone42> sipa: the size of your serialized unspent txout is about the same as piuk's account ledger (https://bitcointalk.org/index.php?topic=52859.40)
126 2012-06-15 11:58:13 <gmaxwell> As it should be.
127 2012-06-15 11:58:36 <sipa> which means you don't gain much by trying to maintain a balance per address
128 2012-06-15 11:58:55 <gmaxwell> Account ledgers are a bad idea  bitcoin has zilcho privacy if you don't use pseudorandom addresses.
129 2012-06-15 11:59:04 <sipa> indeed
130 2012-06-15 11:59:15 <sipa> it's side effect of currently using key id's as addresses
131 2012-06-15 12:15:43 <sipa> justmoon, gmaxwell: 67 MiB!
132 2012-06-15 12:15:55 <justmoon> well done :)
133 2012-06-15 12:19:14 <da2ce7> 1000 things to do.... the time of 10
134 2012-06-15 12:19:25 <justmoon> da2ce7: cloning ftw
135 2012-06-15 12:19:39 <da2ce7> :)
136 2012-06-15 12:19:47 <justmoon> also protip: stay out of irc :P
137 2012-06-15 12:20:08 <justmoon> "scale out, not up!"
138 2012-06-15 12:20:18 <sipa> oh wait, seems i just made you female
139 2012-06-15 12:20:51 <justmoon> that channel is just for nerds, this channel were the cool people are!
140 2012-06-15 12:20:55 <justmoon> where*
141 2012-06-15 12:21:05 <justmoon> is* where
142 2012-06-15 12:21:12 <justmoon> also the people who can't spell apparently
143 2012-06-15 12:21:19 <sipa> wait... nerds's can't be cool? :(
144 2012-06-15 12:21:35 <justmoon> don't put words in my mouth :P
145 2012-06-15 12:21:44 <justmoon> I say enough stupid things as it is
146 2012-06-15 12:22:36 <jgarzik> darn, TD just disappeared
147 2012-06-15 12:23:18 <da2ce7> with your wallet format I can pick a 'random position' on a 'observe only' chain... then tell the person with the private chain that position.
148 2012-06-15 12:23:23 <jgarzik> sipa: so, I agree with TD that adding 'mempool' P2P command would be a simple and useful first step towards [diagnostics | SPV | filtering]
149 2012-06-15 12:23:33 <jgarzik> sipa: so... return a huge 'inv' from that?
150 2012-06-15 12:23:55 <jgarzik> think a 10,000 entry inv or whatever
151 2012-06-15 12:27:26 <sipa> jgarzik: just use pushinventory or something like that; the network code will combine it into a single inv message
152 2012-06-15 12:27:42 <jgarzik> ok
153 2012-06-15 12:29:49 <da2ce7> sipa: I had the idea where we could have a new kind of bitcoin address where the sender 'picks at random' the public key they are sending to... then sends the 'position' of that public key to the holder of the extended private key.
154 2012-06-15 12:30:30 <sipa> da2ce7: addresses shouldn't be chosen by a sender
155 2012-06-15 12:30:41 <da2ce7> so by publishing publicly this bitcoin address... without know each position of every sender... you cannot track the coins.
156 2012-06-15 12:30:46 <jgarzik> sipa: does pushinventory broadcast to all connected, or just the requestor?
157 2012-06-15 12:30:57 <sipa> jgarzik: oh, to all, i suppose
158 2012-06-15 12:31:02 <sipa> right
159 2012-06-15 12:31:53 <sipa> da2ce7: if you're going to introduce a communication step anyway, there are better ways to protect privacy
160 2012-06-15 12:33:19 <da2ce7> sipa: the position is one-way communcation and dosn't matter if it is made public:
161 2012-06-15 12:33:24 <da2ce7> kinda like ( public extended key ) > random 256bit position > bitcoin address.
162 2012-06-15 12:33:28 <da2ce7> send to bitcoin address.
163 2012-06-15 12:33:37 <da2ce7> then send in email the random 256bit position
164 2012-06-15 12:34:04 <sipa> it is one-way, and offline
165 2012-06-15 12:34:11 <sipa> which may be useful in some scenarios
166 2012-06-15 12:35:50 <da2ce7> that means I can convince the seller that I sent the bitcoins... just by sending that 256bit position in a email... or however.
167 2012-06-15 12:40:32 <BlueMatt> are our merkle trees deterministic for a given set of transaction hashes? ie do they have to be place in a certain rder?
168 2012-06-15 12:41:01 <justmoon> if the set is in a given order the merkle tree will be too
169 2012-06-15 12:41:04 <BlueMatt> placed in a certain order
170 2012-06-15 12:41:16 <BlueMatt> justmoon: thats my question, is the set in a given order?
171 2012-06-15 12:41:19 <sipa> BlueMatt: no
172 2012-06-15 12:41:23 <BlueMatt> darn...
173 2012-06-15 12:41:41 <sipa> and it's quite hard to come up with a canonical order
174 2012-06-15 12:41:42 <BlueMatt> that would have been really nice
175 2012-06-15 12:41:49 <justmoon> now I'm curious what cool optimization you have come up with :D
176 2012-06-15 12:42:01 <BlueMatt> sipa: sorted by hash?
177 2012-06-15 12:42:20 <sipa> BlueMatt: yes, you can do that, but that'd mean a lot more recalculations
178 2012-06-15 12:42:22 <BlueMatt> justmoon: well you just dont need to transfer the merkle tree, you can just give a list of txes and the remote side would have it
179 2012-06-15 12:42:31 <sipa> as every insert will essentially mean recalculating the whole thing
180 2012-06-15 12:42:46 <justmoon> well, can't you just give the list of txs in the correct order?
181 2012-06-15 12:42:49 <BlueMatt> true, but its not a huge deal to work around
182 2012-06-15 12:43:52 <sipa> i wonder if you can build a merkle tree using Hash(a & b, a | b) instead of Hash(a, b)
183 2012-06-15 12:44:20 <sipa> oh, right; that'd only make a single node order-invariant
184 2012-06-15 12:44:22 <sipa> not the entire tree
185 2012-06-15 12:45:11 <BlueMatt> justmoon: yep, dur
186 2012-06-15 12:45:59 <justmoon> bye son!
187 2012-06-15 12:57:48 <gribble> New news from bitcoinrss: jgarzik opened pull request 1470 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1470>
188 2012-06-15 13:00:28 <BlueMatt> jgarzik: should we bump protocol version to indicate support for mempool?
189 2012-06-15 13:02:44 <BlueMatt> or should I be asking oh great version king sipa?
190 2012-06-15 13:03:14 <sipa> ACK on version bump for that
191 2012-06-15 13:37:29 <jgarzik> BlueMatt, sipa: well, a version bump is a consideration, yes.  Three options, as I see it:  (a) bump version, (b) add a "features" command, (c) rely on protocol's natural ability to ignore unknown commands for extensibility
192 2012-06-15 13:38:08 <jgarzik> adding 'features' command is the best option IMO, possibly with a version bump for -that-.  features returns a list of strings indicating various features present/absent.
193 2012-06-15 13:38:39 <gmaxwell> if I need a particular (rare) feature must I then crawl the whole network to find it?
194 2012-06-15 13:38:39 <jgarzik> we don't need to bump the protocol version each time we add a P2P command, when the implementation is fully capable of ignoring unknown commands
195 2012-06-15 13:39:28 <jgarzik> gmaxwell: if you need a rare protocol version you must crawl the whole network to find it.  zero effective difference between proposals.
196 2012-06-15 13:45:57 <luke-jr> gmaxwell: mandatory features could be a service bit, which is broadcast with the address type
197 2012-06-15 13:47:40 <sipa> jgarzik: except that nServices is relayed and stored in addrman
198 2012-06-15 13:48:04 <gmaxwell> luke-jr: right, thats where i was going.
199 2012-06-15 13:48:05 <sipa> so i suppose nServices is actually better
200 2012-06-15 13:48:37 <luke-jr> I see no reason to use it for *this* particular change tho
201 2012-06-15 13:49:48 <sipa> also, the nServices could would need to be tested and probably extended
202 2012-06-15 13:51:26 <luke-jr> maybe nServices assignments should be temporary: another feature negotiation is the "real" mechanism, and once FeatureX has enough adoption, its nServices bit is reallocated (inverted) for future use
203 2012-06-15 13:51:42 <luke-jr> eg, 8 bits later we use "if it's 0, FeatureY is supported"
204 2012-06-15 13:52:01 <luke-jr> at least for upgrade-based features
205 2012-06-15 13:59:57 <BlueMatt> jgarzik: the way I see as good for mempool is version bump and !fClient
206 2012-06-15 14:00:18 <BlueMatt> jgarzik: that way you can tell from what is relayed and stored in addr
207 2012-06-15 14:00:33 <BlueMatt> and no, we dont need a version bump for every feature, but as long as it makes sense, we might as well
208 2012-06-15 14:01:19 <BlueMatt> and I see little reason to not version bump here, and no reason to waste one of our services flags, since all !fClients that are of a certain version should be able to handle mempool
209 2012-06-15 14:16:40 <gavinandresen> Morning everybody.  I'm hacking up a version of bitcoind to record how fast or slow transactions stay in the memory pool before getting into a block.  Nobody's already done that, right?
210 2012-06-15 14:17:57 <luke-jr> gavinandresen: I know I saw a site doing it
211 2012-06-15 14:18:07 <ThomasV> gavinandresen: bitcoinstats.org
212 2012-06-15 14:18:11 <luke-jr> http://bitcoinstats.org/
213 2012-06-15 14:18:12 <luke-jr> yeah
214 2012-06-15 14:18:38 <gavinandresen> I need (fee,size,priority,time_in_mempool)
215 2012-06-15 14:19:05 <luke-jr> gavinandresen: priority is dynamic
216 2012-06-15 14:19:19 <luke-jr> gavinandresen: and changes a bit with txn_prio pullreq
217 2012-06-15 14:19:27 <gavinandresen> right, priority when it entered the pool
218 2012-06-15 14:19:28 <ThomasV> gavinandresen: transactions should expire after maybe 144 blocks. (blocks that contain expired tx should be rejected)
219 2012-06-15 14:19:40 <gavinandresen> ThomasV: okey dokey
220 2012-06-15 14:20:01 <luke-jr> ThomasV: &
221 2012-06-15 14:21:19 <gmaxwell> ^ I second that.
222 2012-06-15 14:21:59 <gavinandresen> ("okey dokey" is gavinspeak for "i don't want to think hard about that right now, but my knee-jerk reaction is that it is a bad idea.")
223 2012-06-15 14:22:42 <ThomasV> gavinandresen: that's not what okey dokey sounds like
224 2012-06-15 14:22:53 <gavinandresen> okey dokey
225 2012-06-15 14:23:35 <ThomasV> if transactions expire after a day, users have a guarantee that they can still reuse their coins. it would feel safer than the current limbo
226 2012-06-15 14:23:54 <luke-jr> ThomasV: that's a guarantee they shouldn't get.
227 2012-06-15 14:24:03 <luke-jr> and trying to do it is asking for forks
228 2012-06-15 14:24:33 <ThomasV> luke-jr: your hashing power is too small for that :)
229 2012-06-15 14:24:42 <luke-jr> ThomasV: it has nothing to do with hashing power
230 2012-06-15 14:24:47 <ThomasV> lol I know
231 2012-06-15 14:25:12 <luke-jr> instead, users can be enabled to select transactions and right-click "Replace" and create a new txn using the same inputs
232 2012-06-15 14:25:14 <ThomasV> anyway, the memorypool market should be improved
233 2012-06-15 14:25:27 <luke-jr> once that transaction is confirmed, the others can be marked as invalid
234 2012-06-15 14:26:20 <ThomasV> luke-jr: that too. but that's not a fork
235 2012-06-15 14:26:34 <ThomasV> it's something we can do right now
236 2012-06-15 14:27:14 <ThomasV> if the new tx has a higher fee, miners will naturally prefer it
237 2012-06-15 14:27:34 <luke-jr> ThomasV: forks are bad
238 2012-06-15 14:27:58 <ThomasV> luke-jr: expiring transactions is not a bad fork
239 2012-06-15 14:29:01 <luke-jr> ThomasV: expiring transactions hard is a "forks happening every day" scenario
240 2012-06-15 14:29:12 <ThomasV> the uncertainty about your coins staying in limbo for an undetermined amount of time is bad. it does not help building confidence in the currency
241 2012-06-15 14:29:17 <luke-jr> because nodes do not and will not agree on when they expire
242 2012-06-15 14:29:29 <sipa> it don't see how expiring transactions from the memory pool can cause forks
243 2012-06-15 14:29:42 <luke-jr> ThomasV: then propose a patch that automatically does a send-to-change of "expired" txns
244 2012-06-15 14:29:48 <luke-jr> sipa: he wants to make blocks including them invalid
245 2012-06-15 14:30:04 <sipa> ThomasV: are you?
246 2012-06-15 14:30:15 <luke-jr> [16:19:27] <ThomasV> gavinandresen: transactions should expire after maybe 144 blocks. (blocks that contain expired tx should be rejected)
247 2012-06-15 14:30:15 <ThomasV> yes
248 2012-06-15 14:30:20 <sipa> oh
249 2012-06-15 14:30:23 <sipa> that's a horrible idea
250 2012-06-15 14:30:27 <ThomasV> why?
251 2012-06-15 14:30:41 <sipa> the validity of a transaction can never turn from valid to invalid once it is in a block
252 2012-06-15 14:30:55 <sipa> otherwise reorganisations could lead to massive chains of transactions becoming invalid
253 2012-06-15 14:31:21 <BlueMatt> expiring txes from memory pool after N is a good idea, rejecting blocks based on that is broken
254 2012-06-15 14:31:29 <sipa> what BlueMatt said
255 2012-06-15 14:31:52 <ThomasV> I don't get it. what is the difference?
256 2012-06-15 14:32:18 <luke-jr> I think we can get ThomasV's desired behaviour with an automatic send-to-change in the client
257 2012-06-15 14:32:20 <BlueMatt> if you reject blocks based on that, individual nodes can disagree about the validity of a block, which is not good
258 2012-06-15 14:32:42 <luke-jr> ThomasV: nodes don't know the time a transaction was broadcast
259 2012-06-15 14:32:51 <luke-jr> ThomasV: they only know when they received it - which can vary greatly
260 2012-06-15 14:32:51 <ThomasV> wait, that's not what I meant
261 2012-06-15 14:33:00 <ThomasV> you want to put the block number in the tx
262 2012-06-15 14:33:23 <luke-jr> ok, but that still has the problem sipa pointed out
263 2012-06-15 14:33:35 <sipa> ThomasV: there are several interpretations of what you said above, but i think all of them are flawed (but maybe i miss one)
264 2012-06-15 14:33:56 <sipa> the worst case interpretation is that every output coin must be spent within 144 blocks, or it becomes invalid
265 2012-06-15 14:34:10 <ThomasV> I said that blocks should be rejected so that the owner of the coins knows for sure that he can reuse them
266 2012-06-15 14:34:32 <sipa> ok, specify me the exact rule for rejecting a transaction
267 2012-06-15 14:34:39 <sipa> eh, a block
268 2012-06-15 14:34:47 <jgarzik> back from lunch
269 2012-06-15 14:35:03 <jgarzik> BlueMatt: version bump does not make much sense, as a memory pool is not a requirement of a network node
270 2012-06-15 14:35:37 <BlueMatt> no, but no network nodes of a given protocol version will not have mempool
271 2012-06-15 14:35:39 <ThomasV> sipa: include exation height in the tx. block that contains expired tx is rejected
272 2012-06-15 14:35:40 <jgarzik> thus "mempool" command may simply be absent (we don't want to require thin nodes to implement commands that simply return an empty vector)
273 2012-06-15 14:35:46 <ThomasV> *expiration*
274 2012-06-15 14:35:59 <jgarzik> BlueMatt: bump version for "feature" message, discover from there
275 2012-06-15 14:36:17 <BlueMatt> jgarzik: but if (fClient) mempool should not be implemented, hence why I think a check makes sense
276 2012-06-15 14:36:21 <jgarzik> or really we should just go ahead with "list-commands" command, which can do the same thing
277 2012-06-15 14:36:24 <sipa> ThomasV: NAK; what if there is a reorganisation that moves a transaction over its expiration time?
278 2012-06-15 14:36:26 <BlueMatt> jgarzik: and returning is the same as not implementing
279 2012-06-15 14:36:37 <sipa> ThomasV: it would mean invalidating everything that depends on it, and was already confirmed
280 2012-06-15 14:36:47 <jgarzik> BlueMatt: yes... and that then does not help with detection
281 2012-06-15 14:37:03 <BlueMatt> jgarzik: when there is more than one full node implementation, it makes sense to not do so, but while there is only one it doesnt make sense to add a services flag just for mempool
282 2012-06-15 14:37:04 <luke-jr> sipa: would my alternative implementation work?
283 2012-06-15 14:37:36 <sipa> luke-jr: can you elaborate
284 2012-06-15 14:37:46 <BlueMatt> anyway, it really isnt a big deal either way, just do something so that nodes can tell if a given node has mempool from the info forwarded via addr messages
285 2012-06-15 14:37:58 <luke-jr> sipa: after N blocks, the client automatically rebroadcasts or broadcasts a send-to-self-change-address based on user config
286 2012-06-15 14:38:12 <ThomasV> sipa: by definition, such a reorg would not "move" the tx, it would not be allowed to contain it anymore
287 2012-06-15 14:38:13 <luke-jr> sipa: when the latter is confirmed, it shows the originals as invalid
288 2012-06-15 14:38:49 <sipa> ThomasV: exactly; and that means invalidating everything that depended on it
289 2012-06-15 14:39:27 <sipa> ThomasV: right now, a reorganisation introduced a renewed chance for double-spending, but in case of an honest sender, 0 chance for invalidation
290 2012-06-15 14:39:37 <sipa> ThomasV: with your rule, that would change
291 2012-06-15 14:40:33 <ThomasV> sipa: I see. but is that a big deal?
292 2012-06-15 14:40:55 <luke-jr> "your transaction got reversed for no reason; please resend"
293 2012-06-15 14:41:18 <luke-jr> ThomasV: is that a serious question?
294 2012-06-15 14:41:36 <sipa> i really don't want confirmed transactions to be reversed
295 2012-06-15 14:41:54 <sipa> especially since gets confirmations is imho the responsibility of the receiver and not of the sender
296 2012-06-15 14:41:59 <ThomasV> it seems to me that the benefits outweight the inconvenience, unless you set a ridiculously small expiration interval
297 2012-06-15 14:42:03 <sipa> and the receiver *cannot* create a new transaction
298 2012-06-15 14:42:45 <luke-jr> I don't see any benefit to expiring transactions.
299 2012-06-15 14:42:55 <luke-jr> at the high-level user end
300 2012-06-15 14:43:09 <luke-jr> (at the low-level, the benefit is so the user can add fees)
301 2012-06-15 14:44:44 <jgarzik> <BlueMatt> just do something so that nodes can tell if a given node has mempool from the info forwarded via addr messages  <<-- why, specifically?
302 2012-06-15 14:45:05 <BlueMatt> so as an spv client you dont have to scan the network to find a mempool-responding node
303 2012-06-15 14:45:06 <jgarzik> because it sounds like you want a higher level rule
304 2012-06-15 14:45:16 <jgarzik> e.g. "I am a full node"
305 2012-06-15 14:45:20 <BlueMatt> I mean you can just live without it, but it would be nice...
306 2012-06-15 14:45:35 <jgarzik> mempool-responding is too fine-grained to advertise.  "I provide services to SPV" is not.
307 2012-06-15 14:45:54 <BlueMatt> the fClient assert -> The idea is as long as its the reference implementation, we make it clear that spv clients should not be responding to mempool requests
308 2012-06-15 14:45:57 <jgarzik> because I promise you, there will be many more details required of SPV-servicing nodes
309 2012-06-15 14:46:13 <BlueMatt> jgarzik: agreed, hence why I said just make it a requirement for full nodes of a given version
310 2012-06-15 14:46:40 <BlueMatt> (because its not like full nodes of a given version /wont/ implement it)
311 2012-06-15 14:47:04 <jgarzik> in general fClient is the wrong direction
312 2012-06-15 14:47:12 <jgarzik> we need fServer / fFullNode
313 2012-06-15 14:47:34 <jgarzik> you assert that you -have- resources, and everything else may legally be a subset
314 2012-06-15 14:47:48 <sipa> jgarzik, BlueMatt: i'm implementing my "ultra pruned" idea (which means only retaining unspent txouts + txids permanently, and entirely separate keeping some or all full blocks available); if that works out to be useful, a further splitup of services may be useful
315 2012-06-15 14:48:55 <BlueMatt> sipa: for that, a nServices field makes sense (!fClient should always be only for full-block serving nodes imo)
316 2012-06-15 14:49:29 <sipa> it may make keeping a merkle structure for those unspent txouts viable, and if we can put that in coinbases
317 2012-06-15 14:49:42 <jgarzik> "I'm a crippled client" bits tend to be less useful than "I have certain added features" bits, when widely advertising said bits
318 2012-06-15 14:49:55 <BlueMatt> jgarzik: alright, well as long as we dont waste umpteen nServices fields for parts of fSPVServingNode and as long as we dont end up with a version that has part of the final fSPVServingNode and not all of it (which just gets confusing)
319 2012-06-15 14:50:17 <sipa> yes, i think the current bit0 flag should be redefined to "i do everything"; and then define a few more specific subset bits
320 2012-06-15 14:50:25 <jgarzik> yes
321 2012-06-15 14:50:34 <sipa> bits that say "i do not X" are bad
322 2012-06-15 14:50:42 <jgarzik> correct
323 2012-06-15 14:50:55 <BlueMatt> sipa: agreed, and we dont have any of those atm, so...
324 2012-06-15 14:50:55 <sipa> (especially since the address managing codes automatically ORs them together)
325 2012-06-15 14:51:27 <BlueMatt> !fClient is actually a 1 iirc, and it should continue to defined I have full blocks for serving to old nodes, was my point
326 2012-06-15 14:51:27 <gribble> Error: "fClient" is not a valid command.
327 2012-06-15 14:53:34 <sipa> btw: compressed txout data set to less than 70 MiB already :)
328 2012-06-15 14:54:01 <gavinandresen> !fU
329 2012-06-15 14:54:02 <gribble> Error: "fU" is not a valid command.
330 2012-06-15 14:54:05 <jgarzik> pfrom->fClient = !(pfrom->nServices & NODE_NETWORK)
331 2012-06-15 14:54:32 <BlueMatt> yea, NODE_NETWORK, thats what it was
332 2012-06-15 16:10:58 <luke-jr> hmm
333 2012-06-15 16:11:14 <luke-jr> will I regret asking Diapolo to take over coincontrol? :P
334 2012-06-15 16:12:05 <Joric> luke-jr, thought it was done by coderrr(r)?
335 2012-06-15 16:12:17 <luke-jr> Joric: once upon a time
336 2012-06-15 16:14:09 <Joric> rewatching good wife episode about bitcoins
337 2012-06-15 16:14:11 <Joric> '- Is leakage inevitable? - Leakage is never inevitable. C++ allows for some restrictions based on the complexity of the leakage.'
338 2012-06-15 16:14:15 <Joric> better use C++!
339 2012-06-15 16:14:29 <luke-jr> &
340 2012-06-15 16:22:02 <sturles> I'll repeat a question from earlier now that people are awake: I want to accept bitcoin payments to a web service, and notify the user as soon as coins are received.  Before any confirmations.  For security reasons I don't want a live wallet on the server.  Is there some modified bitcoind or other tool which can monitor a list of addresses on the P2P network and trig as soon as one of the addresses receive a payment?
341 2012-06-15 16:22:17 <sturles> I want to keep the private keys on a completely separate server, which is offline except when I need the coins.
342 2012-06-15 16:26:06 <gavinandresen> sturles: easiest way right now would be to encrypt the wallet offline with a 256-bit random password, then use the encrypted wallet as the live wallet.  Never unencrypt it on the live server.
343 2012-06-15 16:26:51 <sturles> Of course!  That would work.  Thanks!
344 2012-06-15 16:31:59 <sturles> Is there a way to stream listtransactions or get a signal when a transaction arrives to a know address, or do I need to poll?
345 2012-06-15 16:33:34 <gavinandresen> sturles: you need to poll.  -blocknotify will tell you when new blocks appear, but there is no api yet for new transaction notification
346 2012-06-15 16:38:50 <sturles> Would it be a simple patch for a novice C programmer with only slight knowledge of C++, or should I just forget about it and poll?
347 2012-06-15 16:39:45 <luke-jr> sturles: jgarzik has a filter thing
348 2012-06-15 16:45:08 <sturles> This one? https://github.com/jgarzik/bitcoin/commit/102b1be44dcb0d2645ba1e32fdcb226c6febcdd2
349 2012-06-15 16:45:55 <luke-jr> no, that's old
350 2012-06-15 16:46:01 <luke-jr> https://github.com/bitcoin/bitcoin/pull/1386 has the latest one
351 2012-06-15 16:49:36 <sturles> Thanks.  I'll test.
352 2012-06-15 17:24:40 <Joric> ctrl+f 1dice on http://bitcoincharts.com/bitcoin/txlist/
353 2012-06-15 17:24:49 <Joric> sick
354 2012-06-15 17:25:05 <gmaxwell> This isn't news.
355 2012-06-15 17:26:05 <Joric> gambling bots? seems the stupidiest idea ever
356 2012-06-15 17:26:27 <gmaxwell> Yep.
357 2012-06-15 17:27:38 <gmaxwell> Prior conversation on OTC suggests that a lot of people are failing at math and actually thinking that "Martingale" turns the expectation positive.
358 2012-06-15 17:28:47 <gmaxwell> (with people like bitcoin "fund managers" writing bots for this. People are even selling bots for it.)
359 2012-06-15 17:29:31 <bogodyson> lol
360 2012-06-15 17:29:38 <bogodyson> i love those kinda people gmaxwell
361 2012-06-15 17:29:58 <gmaxwell> Suckers?
362 2012-06-15 17:30:00 <bogodyson> cause its kinda funny when their assumptions lead them to fall spectacularly hard on their face
363 2012-06-15 17:30:15 <Joric> it's the same classical gambler's fallacy, right?
364 2012-06-15 17:30:30 <Diablo-D3> "fund manager"
365 2012-06-15 17:30:36 <gmaxwell> Yes, or at least closely related.
366 2012-06-15 17:30:37 <Diablo-D3> you mean 5 lines of perl.
367 2012-06-15 17:31:10 <copumpkin> wtf
368 2012-06-15 17:31:18 <copumpkin> a martingale bot?
369 2012-06-15 17:31:21 <TuxBlackEdo> people still use perl?
370 2012-06-15 17:31:26 <copumpkin> ???_???
371 2012-06-15 17:31:53 <Diablo-D3> I do :<
372 2012-06-15 17:31:53 <gmaxwell> Joric: that betting practice turns a game with a high odds of small loss to a game with low odds of enormous loss. People confuse the sequence of wins they get for something positive and then are confused when they wipe out on their sure thing betting strategy.
373 2012-06-15 17:32:44 <gmaxwell> Joric: also, people actually misunderstand randomness.  I ran a study a while back that showed people pairs of sequences like ABBABABAAABABA   and asked which one they through was more or less random.
374 2012-06-15 17:33:11 <gmaxwell> And I got 10:1 preference for a very not random sequence one where long runs of a single letter were artifically removed.
375 2012-06-15 17:33:26 <Diablo-D3> gmaxwell: really?
376 2012-06-15 17:33:37 <gmaxwell> So when people imagine their random gambling outcomes they don't forsee runs of a dozen losses that would take millions in bets to recover from.
377 2012-06-15 17:33:43 <Diablo-D3> arent all random sequences... random?
378 2012-06-15 17:34:12 <Karmaon> what that makes no sense.
379 2012-06-15 17:34:24 <Joric> they all equal probability if i remember right
380 2012-06-15 17:34:33 <Diablo-D3> I mean, if you showed me a bunch of strings
381 2012-06-15 17:34:37 <Diablo-D3> asking me if I thought it looked random
382 2012-06-15 17:34:42 <Diablo-D3> for any given string, I would say yes.
383 2012-06-15 17:35:29 <Diablo-D3> even if you showed me strings that only have A through E in them, and one of them had a Z
384 2012-06-15 17:35:36 <Diablo-D3> the machine generating it had a random failure.
385 2012-06-15 17:36:10 <Karmaon> is aaaaaa more or less random than bbbbbbb? i don't know.
386 2012-06-15 17:36:18 <Diablo-D3> Karmaon: they're both random
387 2012-06-15 17:36:28 <Karmaon> maybe you changed all the letters of the second set to b.
388 2012-06-15 17:36:30 <gmaxwell> http://people.xiph.org/~greg/cgi-bin/random0.py  < one version of the test.  I had a good couple hundred people take it in varrious forms.
389 2012-06-15 17:36:34 <Diablo-D3> show me the entire text of the constitution?
390 2012-06-15 17:36:41 <Diablo-D3> its likely randomly generated.
391 2012-06-15 17:36:48 <gmaxwell> And the results were reliable and repeatable however I asked the question or laid it out.
392 2012-06-15 17:37:03 <gmaxwell> People don't believe actually uniformly random squences are random.
393 2012-06-15 17:37:15 <Diablo-D3> gmaxwell: I do
394 2012-06-15 17:37:18 <Diablo-D3> infact they're bastardly
395 2012-06-15 17:37:20 <Diablo-D3> I hate them
396 2012-06-15 17:37:26 <Karmaon> gmaxwell: that link is asking for abuse.
397 2012-06-15 17:37:27 <Diablo-D3> but I do believe they are random
398 2012-06-15 17:37:28 <gmaxwell> Well you're tainted now, so thats no good.
399 2012-06-15 17:37:32 <jgarzik> gmaxwell: it's how the brain works.  we match patterns instinctually.
400 2012-06-15 17:37:37 <Diablo-D3> gmaxwell: that test makes no sense
401 2012-06-15 17:37:41 <Diablo-D3> why do I have to choose?
402 2012-06-15 17:37:44 <Diablo-D3> they are both equally random
403 2012-06-15 17:37:55 <gmaxwell> Diablo-D3: they are not equally random. One is less random.
404 2012-06-15 17:38:08 <TuxBlackEdo> gmaxwell, just like tests back in college.. i am stuck on the first problem x_x
405 2012-06-15 17:38:14 <Diablo-D3> gmaxwell: I mean
406 2012-06-15 17:38:22 <Diablo-D3> both are fine examples of random output from an oracle
407 2012-06-15 17:38:55 <gmaxwell> Diablo-D3: if you take the test many times you will be able to predict the values better than chance, because one of the options always has less entropy.
408 2012-06-15 17:39:16 <Diablo-D3> but you cannot measure entropy with such a smal sample
409 2012-06-15 17:39:20 <Diablo-D3> I'd need a string of several pages
410 2012-06-15 17:39:23 <wizkid057> So, I'm just going to chime in on this real quick.  Up until recently I was running and maintaining bitcoind on about two dozen machines, just to add peers (which helps!).  Well, within the past month or so, bitcoind's CPU usage on all of the machines I run it on has gone up insanely, forcing me to remove it from all but two.
411 2012-06-15 17:39:42 <Karmaon> wizkid057: satoshidice anyone?
412 2012-06-15 17:39:54 <wizkid057> Karmaon: was saying it without saying it...
413 2012-06-15 17:39:59 <gmaxwell> wizkid057: bummer. :(
414 2012-06-15 17:40:08 <Diablo-D3> gmaxwell: so how do I see my own results?
415 2012-06-15 17:40:29 <gmaxwell> Diablo-D3: you can't, because I don't even remember how to decode them anymore.
416 2012-06-15 17:40:40 <Diablo-D3> lol
417 2012-06-15 17:40:40 <gmaxwell> that script is from like .. 2009.
418 2012-06-15 17:41:15 <wizkid057> Well, I just felt the need to point this out since I assume others will eventually realize the increase in resource usage and do the same.
419 2012-06-15 17:41:53 <Karmaon> wizkid057: you cannot expect everyone to run full nodes, it will phase out sooner or later
420 2012-06-15 17:42:14 <wizkid057> Karmaon: seems the need is sooner rather than later :)
421 2012-06-15 17:42:19 <gmaxwell> p2pool has responded to slow block processing by relaying headers and mining empty blocks until the local bitcoind catches up with the chain.
422 2012-06-15 17:42:45 <gmaxwell> Karmaon: but there is a fine line between everyone and anyone.
423 2012-06-15 17:42:52 <wizkid057> gmaxwell: well, theres absolutely no benefit to the miner to mine anything but empty blocks...
424 2012-06-15 17:43:04 <gmaxwell> wizkid057: fees.
425 2012-06-15 17:43:11 <wizkid057> gmaxwell: fees might as well be nothing
426 2012-06-15 17:43:20 <gmaxwell> Yep, or at least almost.
427 2012-06-15 17:43:34 <gmaxwell> I think they're up to 0.04 btc/block on average now.
428 2012-06-15 17:44:25 <gmaxwell> wizkid057: but when bitcoind's slowness wasn't causing orphaning it wasn't worth _not_ mining transactions.
429 2012-06-15 17:44:58 <wizkid057> i mean, I had bitcoind running on some pretty beefy machines
430 2012-06-15 17:45:16 <wizkid057> and it was using substantial amounts of resources (memory, cpu, disk io)
431 2012-06-15 17:45:29 <Joric> i sent f8e0a0162f2eee7f233f1a87855d5021ec9b808f505d5ff385c2f7d56eaa6086 a few hours ago without being asked for a fee, any eta?
432 2012-06-15 17:45:34 <wizkid057> and it wasnt before satoshispam started
433 2012-06-15 17:48:02 <gmaxwell> wizkid057: a little odd.. so a node here with about 30 hours uptime and 23 peers shows 8:21.59 total cpu time. 8 minutes in 30 hours isn't much.
434 2012-06-15 17:48:18 <gmaxwell> oh well never mind. It's modified to drop all those transactions, so not a good comparison.
435 2012-06-15 17:48:24 <wizkid057> haha
436 2012-06-15 17:48:27 <wizkid057> hmm
437 2012-06-15 17:48:31 <wizkid057> care to share this mod?
438 2012-06-15 17:48:33 <gmaxwell> but it at least has the blockchain load.
439 2012-06-15 17:48:35 <wizkid057> i'll fire the nodes up again
440 2012-06-15 17:48:36 <wizkid057> lol
441 2012-06-15 17:49:19 <gmaxwell> wizkid057: All I did is crank the fees up on that one. You're welcome to the patch, one sec.   But I was wondering if the fact that it runs out of tmpfs might have mattered ... e.g. is iowait being misreported as cpu.
442 2012-06-15 17:50:00 <gmaxwell> (I'm hesitant to share other patches I have that single out some senders...)
443 2012-06-15 17:50:20 <wizkid057> lol
444 2012-06-15 17:51:13 <gmaxwell> http://people.xiph.org/~greg/nofree.nocheap.patch
445 2012-06-15 17:54:45 <wizkid057> hmm... thats simpler than I expected
446 2012-06-15 17:54:47 <wizkid057> thanks :)
447 2012-06-15 17:57:19 <ThomasV> my bitcoind segfaults on startup. (0.6.2). I guess I corrupted one of the files in .bitcoin. which one could that be?
448 2012-06-15 17:58:00 <luke-jr> probably addr.dat <.<
449 2012-06-15 17:58:07 <luke-jr> at least, that's easiest to delete
450 2012-06-15 17:58:26 <ThomasV> how much time will it take to rebuild?
451 2012-06-15 17:58:47 <luke-jr> it doesn't need to rebuild
452 2012-06-15 17:59:00 <luke-jr> it's basically a random cache of IPs
453 2012-06-15 17:59:04 <ThomasV> ok
454 2012-06-15 17:59:44 <ThomasV> hmm, no, it wasnt that one :)
455 2012-06-15 18:03:03 <gmaxwell> are you getting any information besides the fault? anything in the log?
456 2012-06-15 18:03:21 <ThomasV> the log is not empty, but nothing related afaict
457 2012-06-15 18:03:54 <ThomasV> oh wait..
458 2012-06-15 18:04:05 <ThomasV> sorry, I had another instance running
459 2012-06-15 18:17:47 <Joric> got confirmed, 185 minutes
460 2012-06-15 18:18:09 <Joric> (1 confirmation)
461 2012-06-15 18:18:43 <Joric> better pay fee!
462 2012-06-15 18:19:15 <Zapsoda> hello??
463 2012-06-15 18:19:32 <wizkid057> gmaxwell: Start May17, 4243:52
464 2012-06-15 18:19:55 <wizkid057> gmaxwell: 70 hours of CPU time in a month
465 2012-06-15 18:22:55 <wizkid057> namecoind used 134:44 in the same timeframe
466 2012-06-15 18:23:28 <wizkid057> bitcoind -testnet used 50:51
467 2012-06-15 19:53:12 <jurov> hi all, reminder to everyone who needs just to solve resource problem
468 2012-06-15 19:53:31 <jurov> if this would solve it:https://bitcointalk.org/index.php?topic=71542.msg962126#msg962126 please donate
469 2012-06-15 19:54:31 <luke-jr> that doesn't solve anything
470 2012-06-15 19:55:33 <jurov> okay, it won't help everyone... but it is also relatively easily done
471 2012-06-15 19:55:52 <jurov> the 2-wallet prototype is already working
472 2012-06-15 19:56:40 <gmaxwell> ugh. ... why are they doing that. bleh.
473 2012-06-15 19:57:19 <luke-jr> jurov: it's easily done because we're working on *proper* multiwallet support
474 2012-06-15 19:57:45 <jurov> which branch?
475 2012-06-15 19:58:10 <luke-jr> I think git master has the latest.
476 2012-06-15 19:58:16 <luke-jr> it's being done in steps
477 2012-06-15 19:58:22 <gmaxwell> jurov: bluematt's blockstore/hub patches for example.
478 2012-06-15 19:58:37 <luke-jr> until recently, the wallet didn't have a clearly isolated class
479 2012-06-15 19:58:57 <gmaxwell> It's a major architectural change, the functionality doesn't become visible until the very end.
480 2012-06-15 19:59:37 <jurov> yep, already noticed it's half done.
481 2012-06-15 20:06:34 <jurov> so, it seems it's actively being worked on... dunno why rg and neofutur think otherwise
482 2012-06-15 20:08:38 <Diapolo> luke-jr: Can you tell me if FIRST_CLASS_MESSAGING is just a define introduced by you or has it something to do with a specific OS / Qt GUI feature?
483 2012-06-15 20:09:10 <luke-jr> Diapolo: it's a Bitcoin-Qt compile-time feature
484 2012-06-15 20:09:44 <luke-jr> Diapolo: I can probably help you with it, just busy right this second
485 2012-06-15 20:10:35 <Diapolo> But it's not something like Unity or MS Aero or official OS GUI stuff ... it is a define you use to specify a different layout / GUI for the sign/verify part in the GUI?
486 2012-06-15 20:10:49 <luke-jr> yes
487 2012-06-15 20:11:04 <luke-jr> it's basically "consider messaging a main feature, not hide it off in the menu"
488 2012-06-15 20:11:11 <Diapolo> OMFG ... I really had the impression it was something fancy and complex ^^ call me dumbass :D
489 2012-06-15 20:11:23 <luke-jr> Diapolo: so basically, something useful for merchants who use sign/verify a lot
490 2012-06-15 20:11:33 <weex> jurov: probably because neither are devs on the bitcoin project itself, a bounty could be considered a form of feature request
491 2012-06-15 20:11:34 <luke-jr> (and users who sign a lot)
492 2012-06-15 20:11:41 <Diapolo> oh god I start understanding ...
493 2012-06-15 20:11:59 <luke-jr> weex: sipa and BlueMatt are regular devs here
494 2012-06-15 20:12:02 <Diapolo> now it makes sense and I'm sure I can fix this for myself ^^
495 2012-06-15 20:12:09 <weex> luke-jr: i mean rg and neofutur
496 2012-06-15 20:12:13 <luke-jr> Diapolo: great :
497 2012-06-15 20:12:21 <luke-jr> weex: ah
498 2012-06-15 20:12:22 <weex> maybe jurov can update that thread with a pointer to what he found
499 2012-06-15 20:17:07 <luke-jr> weex: actually, in practice rg knows
500 2012-06-15 20:17:08 <jurov> link to bluematt's cod eis alterady there, whether bluematt actually has the same thing in mind as me is not clear
501 2012-06-15 20:17:16 <luke-jr> weex: but when I mentioned it to him, he said he didn't want to wait
502 2012-06-15 20:17:17 <luke-jr> :p
503 2012-06-15 21:03:55 <Diapolo> luke-jr: the general term for signing and verifying is messaging here, right?
504 2012-06-15 21:05:01 <rav3n_pl> hey. any news about https://bitcointalk.org/index.php?topic=87768.0 ? It is really pain, PC is freezing :/
505 2012-06-15 21:11:05 <luke-jr> Diapolo: yes
506 2012-06-15 21:11:27 <luke-jr> rav3n_pl: probably SatoshiDICE
507 2012-06-15 21:12:01 <rav3n_pl> ?
508 2012-06-15 21:12:12 <luke-jr> they're spamming the Bitcoin network
509 2012-06-15 21:12:18 <rav3n_pl> each transaction eats my cpu?
510 2012-06-15 21:12:57 <luke-jr> &yes
511 2012-06-15 21:13:06 <luke-jr> that's how Bitcoin is secure
512 2012-06-15 21:13:13 <luke-jr> every user verifies everything
513 2012-06-15 21:13:57 <sipa> in the long term it isn't expected that every user will run a full node like Bitcoin-Qt implements
514 2012-06-15 21:14:24 <rav3n_pl> i know how it works, just "on paper" verification shoould be "easy nad low computing" lol
515 2012-06-15 21:14:46 <sipa> what kills your system is most likely not the CPU, but the database activity
516 2012-06-15 21:14:47 <luke-jr> rav3n_pl: when there's 9000 transactions?
517 2012-06-15 21:15:08 <luke-jr> sipa: I wonder if non-miners should just verify a random 10% of large blocks
518 2012-06-15 21:15:48 <luke-jr> or perhaps automatically determine the % based on CPU utilization
519 2012-06-15 21:16:13 <sipa> raw CPU is rarely the problem; a normal recent CPU can do 1000s of ECDSA verifications per second
520 2012-06-15 21:16:17 <luke-jr> ie, verify the signatures in random order and after a few seconds assume the rest are good
521 2012-06-15 21:16:24 <luke-jr> hm
522 2012-06-15 21:16:32 <sipa> (but probably not 10000)
523 2012-06-15 21:18:08 <rav3n_pl> hmm lurked in blockchain: largest is one withc over 20 input and few outputs, then 1st - spitting bounty, then anouher 10 i/o and rest is 1-3i/o ... it is one gig trancajction per block
524 2012-06-15 21:19:17 <rav3n_pl> last 10 blocks : 100-800 transactions
525 2012-06-15 21:19:45 <rav3n_pl> bigger was over hour ago
526 2012-06-15 21:19:59 <rav3n_pl> so my client is checking old ones?
527 2012-06-15 21:20:25 <rav3n_pl> 184715     1 hour 34 minutes     897     110,602.34 BTC     Slush     406.03
528 2012-06-15 21:21:41 <rav3n_pl> 2 big transactions in it
529 2012-06-15 21:21:59 <rav3n_pl> still not getting it, also not noticed it on 0.6 client
530 2012-06-15 22:11:48 <gribble> New news from bitcoinrss: jgarzik opened pull request 1471 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1471>
531 2012-06-15 22:36:15 <sipa> gmaxwell: either I have bug, or i compressed the txout set data to 52 MiB :)
532 2012-06-15 22:37:23 <gribble> New news from bitcoinrss: grarpamp opened issue 1472 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1472>
533 2012-06-15 22:37:30 <luke-jr> O.O
534 2012-06-15 22:38:08 <luke-jr> ^ wtf?
535 2012-06-15 22:41:22 <yellowhat> if you load that dataset into memory, how long does it take to filter it for a single address (brute-force without any indexing)
536 2012-06-15 22:42:00 <sipa> yellowhat: not long :)
537 2012-06-15 22:42:17 <yellowhat> 1 ms?
538 2012-06-15 22:42:42 <sipa> it uses key compression for public keys, which means decompression for all spend-to-pubkey outputs
539 2012-06-15 22:42:46 <sipa> and that's slow
540 2012-06-15 22:44:10 <sipa> but if you only need spend-to-keyid, it'd be very fast
541 2012-06-15 22:55:31 <sipa> too, bad, i have bug
542 2012-06-15 22:55:38 <sipa> too bad, i have a bug
543 2012-06-15 22:55:52 <gmaxwell> too bad I, have a bug
544 2012-06-15 22:58:17 <sipa> ok, 68 MiB
545 2012-06-15 22:58:52 <gmaxwell> Are you only compressing pubkeys for that are are you also taking advantage of repeated txouts?
546 2012-06-15 22:59:26 <sipa> no inter-txout tricks
547 2012-06-15 23:01:14 <sipa> i think i should define a special case for txouts with amount = 50.00000000 BTC
548 2012-06-15 23:05:25 <sipa> after piping it through lzma --best: 46 MiB
549 2012-06-15 23:05:57 <Nolybab> i read an interesting article recently about some IP address that was having blocks granted with only a single transaction listed in the block
550 2012-06-15 23:07:32 <Nolybab> anyone know anything about that?
551 2012-06-15 23:11:30 <sipa> ok, final result: 42.8 MiB
552 2012-06-15 23:11:49 <Nolybab> another question perhaps: when a 'coin' is created, please confirm, it's not really a coin at all (no serial number, etc), just an amount that correlates to an account...if one sends BTC it's just transferring value from one account to another, as opposed to transfering a coin 'or portion' thereof, correct?
553 2012-06-15 23:12:03 <sipa> Nolybab: no, wrong
554 2012-06-15 23:12:26 <Nolybab> so an actual 'coin' does exist?
555 2012-06-15 23:12:31 <sipa> Nolybab: bitcoin (at the protocol level) does not know about accounts or addresses, only "transaction outputs"
556 2012-06-15 23:12:50 <Nolybab> understood...
557 2012-06-15 23:13:02 <sipa> each transaction consumes outputs from a previous transaction (which is explicitly referred to), and produces new outputs
558 2012-06-15 23:13:18 <sipa> these outputs are abstract things, they are just defined by the transactions that create them
559 2012-06-15 23:13:26 <sipa> but they are tracked individually
560 2012-06-15 23:13:35 <sipa> and not per address they are assigned to
561 2012-06-15 23:14:03 <Nolybab> ok, that helps clarify
562 2012-06-15 23:15:09 <Nolybab> other than the code, are there any documents about bitcoin, such as architecture diagrams, etc?
563 2012-06-15 23:15:24 <Nolybab> sequence diagrams? use-case diagrams, etc?
564 2012-06-15 23:15:33 <sipa> hardly
565 2012-06-15 23:15:37 <gmaxwell> Nolybab: http://bitcoin.org/bitcoin.pd
566 2012-06-15 23:15:43 <gmaxwell> er http://bitcoin.org/bitcoin.pdf
567 2012-06-15 23:16:04 <Nolybab> i read that
568 2012-06-15 23:16:09 <Nolybab> MANY times :)
569 2012-06-15 23:16:18 <Nolybab> I read every work referenced by it
570 2012-06-15 23:16:25 <Nolybab> and every work referenced by every work
571 2012-06-15 23:16:46 <Nolybab> but thx gmaxwell
572 2012-06-15 23:19:11 <Nolybab> the only thing i haven't really dug into was the code
573 2012-06-15 23:19:18 <Nolybab> <<not a C expert
574 2012-06-15 23:21:36 <Nolybab> so another question about trx inputs/outputs, can they come from anywhere? this suggests that they cascade and stay separate. for instance, if i 'receive' .02 btc from A and .03 btc from B and then send .05 to C, there are two inputs and one output? and if C sends .06 btc to D then that would be at least  3 inputs?
575 2012-06-15 23:22:22 <Nolybab> if you prefer, you can just tell me with src files to review
576 2012-06-15 23:23:20 <[Tycho]> If C sends to D then it will be 2 inputs and 1-2 outputs.
577 2012-06-15 23:23:33 <sipa> or more than 2 inputs, if necessary
578 2012-06-15 23:23:54 <sipa> but it will use the 0.05 coin received from C as one single input
579 2012-06-15 23:24:04 <galambo> bitcoin is not really a currency its a distributed file system containing an accounting database
580 2012-06-15 23:25:32 <sipa> hard to call it a filesystem imho, as it does not provide consistency
581 2012-06-15 23:25:53 <sipa> several nodes are allowed to have a different opinion about the state of the shared data
582 2012-06-15 23:26:10 <sipa> (though it's built in such a way that over time they are exponentially more likely to agree on the past)
583 2012-06-15 23:26:38 <Nolybab> technically, it's BerkleyDB (key-value datastore), and it's not technically a 'distributed' database as it's not sharded or technially a cluster, so much as full replicati
584 2012-06-15 23:26:40 <Nolybab> on
585 2012-06-15 23:27:09 <sipa> well, BDB is an implementation detail; i wasn't talking about that low level :)
586 2012-06-15 23:27:20 <galambo> oh, well thanks for the clarification...
587 2012-06-15 23:28:38 <Nolybab> here's another way for me to approach my question: if i have party A and B, who want to pay entity C, can they do so in a single transaction? (i'm not asking if any client allows it, i'm just asking if there's anything that technically prevents such a scenario?
588 2012-06-15 23:29:00 <Nolybab> i.e. can it be done without changing current data-structure
589 2012-06-15 23:29:09 <sipa> yes
590 2012-06-15 23:29:11 <galambo> the transactions are part of a scripting language, yes
591 2012-06-15 23:29:14 <sipa> that's possible in theory
592 2012-06-15 23:29:17 <Nolybab> cool
593 2012-06-15 23:29:27 <sipa> galambo: scripts have nothing to do with this, actually
594 2012-06-15 23:29:34 <sipa> though you are correct
595 2012-06-15 23:30:01 <galambo> i thought the multisign would be one of the operators im not very familiar with this bit of bitcoin yet
596 2012-06-15 23:30:22 <sipa> you can also send a coin to (A and B), meaning that both A and B must agree and sign the transaction to spend that coin
597 2012-06-15 23:30:31 <sipa> that does requires the scripting system
598 2012-06-15 23:30:42 <Nolybab> ok
599 2012-06-15 23:30:51 <Nolybab> what languge is scripting in?
600 2012-06-15 23:31:12 <sipa> very simple stack-based custom language
601 2012-06-15 23:31:27 <Nolybab> not in original release?
602 2012-06-15 23:31:44 <galambo> yes actually it was from what i understand
603 2012-06-15 23:31:46 <sipa> it's been there forever
604 2012-06-15 23:31:55 <sipa> and it's always been part of the protocol
605 2012-06-15 23:31:58 <Nolybab> oh, ok
606 2012-06-15 23:32:25 <sipa> for "normal" transactions you also use it, but there are only 2 scripts actually created by the client for this
607 2012-06-15 23:34:44 <Nolybab> so, just to clarify, i can theoretically support situations where more than one party can pay into a transaction and pay out to more than one party?
608 2012-06-15 23:34:57 <Nolybab> all within a single transaction
609 2012-06-15 23:35:24 <sipa> yes
610 2012-06-15 23:35:36 <Nolybab> thats' what i wanted to confirm (at least one thing)
611 2012-06-15 23:35:45 <Nolybab> i guess i should have asked it that way to start with :D
612 2012-06-15 23:36:12 <Nolybab> now, about the other thing...did you see my earlier statement about the IP address that is generating only single-transactioblocks?
613 2012-06-15 23:36:33 <sipa> old news :)
614 2012-06-15 23:36:42 <Nolybab> well yeah, to you
615 2012-06-15 23:36:47 <Nolybab> i'm just curious how it resolved
616 2012-06-15 23:36:47 <sipa> supposedly a botnet