1 2013-09-17 00:01:01 <CodeShark> which seems to imply that the engine is just hacking crap together rather than using abstract internal representations
  2 2013-09-17 00:01:19 <sipa> it's just a bunch of macros, afaik
  3 2013-09-17 00:01:49 <Luke-Jr> CodeShark: it is :D
  4 2013-09-17 00:03:22 <gmaxwell> indeed, it's mystical crap. It works surprisingly well considering that its like a duct-taped old car, except there is no car, just ducttape all the way down.
  5 2013-09-17 00:04:02 <sipa> http://uncyclopedia.wikia.com/wiki/File:Ducktape.JPG
  6 2013-09-17 00:05:10 <gavinandresen> speaking of duck tape...
  7 2013-09-17 00:05:31 <gavinandresen> … I'm trying to get rid of the hard-coded fee constants sprinkled throughout our code.
  8 2013-09-17 00:05:45 <phantomcircuit> Luke-Jr, do you have an example for responding to mining.get_transactions ?
  9 2013-09-17 00:05:50 <gavinandresen> And I'm thinking about free transactions and the rules for relaying/mining them....
 10 2013-09-17 00:06:07 <Luke-Jr> phantomcircuit: iirc it's just an array of strings with the raw transactions in hex, in order
 11 2013-09-17 00:06:17 <Luke-Jr> phantomcircuit: Eloipool implements it, if you want a code example
 12 2013-09-17 00:06:20 <phantomcircuit> Luke-Jr, can do
 13 2013-09-17 00:06:52 <gavinandresen> In particular:  the "if you have an output less than {base_fee} then you must pay a fee" rule.
 14 2013-09-17 00:06:56 <gmaxwell> gavinandresen: we could get rid of the 0.01 output rule for all I care.
 15 2013-09-17 00:07:11 <gmaxwell> I see we were thinking of the same rule.
 16 2013-09-17 00:07:22 <gavinandresen> gmaxwell: well, we should fix the comment in the code (it IS {base_fee} and not 0.01)
 17 2013-09-17 00:07:29 <Luke-Jr> side note: currently it's <CENT, not <BaseFee
 18 2013-09-17 00:07:37 <Luke-Jr> it is?
 19 2013-09-17 00:07:49 <gmaxwell> gavinandresen: hm! I suspect it's different things in different places then!
 20 2013-09-17 00:07:51 <gavinandresen> Luke-Jr: I'll double-check the source....
 21 2013-09-17 00:07:59 <Luke-Jr> gavinandresen: I can do that; go on
 22 2013-09-17 00:08:01 <CodeShark> so why do people still invest at all into autotools when clearly there exist far better approaches?
 23 2013-09-17 00:08:24 <Luke-Jr>             if (txout.nValue < CENT)
 24 2013-09-17 00:08:26 <Luke-Jr>                 nMinFee = nBaseFee;
 25 2013-09-17 00:08:30 <gmaxwell> CodeShark: it supports cross compiling and is portable to lots of stuff that you probably don't care about.
 26 2013-09-17 00:08:33 <phantomcircuit> CodeShark, lots and lots of infrastructure
 27 2013-09-17 00:08:39 <Luke-Jr> CodeShark: there aren't better approaches.
 28 2013-09-17 00:09:05 <Luke-Jr> CodeShark: there's a few half-baked attempts that work worse in practice
 29 2013-09-17 00:09:06 <gmaxwell> plus even though it requires mistic sacrifice of goats and funny chants, you can find them in 10001 other packages with some quick searches.
 30 2013-09-17 00:09:09 <gavinandresen> Luke-Jr: I sit corrected
 31 2013-09-17 00:09:40 <phantomcircuit> Luke-Jr, "c"        : is fastest algorithm at 0.00000 MH/s
 32 2013-09-17 00:09:42 <gmaxwell> gavinandresen: in any case, I don't think the CENT rule is actually terribly useful. It certantly complicates coin selection logic.
 33 2013-09-17 00:09:45 <phantomcircuit> that doesn't seem likely
 34 2013-09-17 00:09:53 <Luke-Jr> phantomcircuit: lol
 35 2013-09-17 00:10:06 <gavinandresen> gmaxwell: agreed, I think we should get rid of it.
 36 2013-09-17 00:10:16 <Luke-Jr> IIRC the CENT rule was what we have DUST for now
 37 2013-09-17 00:10:26 <CodeShark> I understand there's craploads of legacy stuff - but given the importance of its function in portability you'd think someone would have already worked on a suitable replacement
 38 2013-09-17 00:10:27 <gavinandresen> gmaxwell: but: it is making me think about what free transactions are for, and avoiding polluting the UTXO set
 39 2013-09-17 00:10:38 <Luke-Jr> but more tolerant of deviation, and less forgiving of amount
 40 2013-09-17 00:11:32 <gmaxwell> gavinandresen: Right, thus was the motivation behind that pull I have with changing the priority to not count the basic scriptsig size.
 41 2013-09-17 00:11:36 <Luke-Jr> I think a "ok, it might be reasonable to send this amount, but it taxes the network a bit and might be abused if let free" rule is good to keep in some form
 42 2013-09-17 00:11:36 <sipa> CodeShark: http://xkcd.com/927/
 43 2013-09-17 00:11:41 <gmaxwell> and right I think CENT is surpassed by DUST.
 44 2013-09-17 00:11:44 <Belxjander> gavinandresen: I've been getting away with free transactions based on when I put money or take money out of different exchange sites... usually exchange->exchange transfers
 45 2013-09-17 00:12:01 <gavinandresen> gmaxwell: yes, I'm looking at that, too.  We talked about making priority a function of #inputs and #outputs
 46 2013-09-17 00:12:12 <gmaxwell> Luke-Jr: It is a bit frustrating that everything there isn't an explicit wall up in front of people regard as a natural right.
 47 2013-09-17 00:12:26 <gavinandresen> If we're going to change the priority calculation, I'd like to do it once, now, because I've been working on code that saves the mempool and priorities to disk
 48 2013-09-17 00:12:52 <Luke-Jr> gmaxwell: I have failed to parse that statement O.o
 49 2013-09-17 00:13:13 <sipa> Luke-Jr: if a door isn't locked, people will assume they're allowed to enter
 50 2013-09-17 00:13:28 <Luke-Jr> oh
 51 2013-09-17 00:13:41 <sipa> my gmaxwelese is getting good these days
 52 2013-09-17 00:13:45 <TheLordOfTime> sipa: heh
 53 2013-09-17 00:13:47 <gmaxwell> gavinandresen: in thinking through it one problem I kept running into is that if you do something like priority = f(outputs-inputs,whatever) that when you have more outputs than inputs to the point where you have "too much priority" then you can have an incentive to add outputs to save up your priority. I was having a hard time avoiding creating that possibility.
 54 2013-09-17 00:14:47 <petertodd> gmaxwell: I ran into a multisig wallet recently that had two change addresses for every tx already...
 55 2013-09-17 00:14:58 <CodeShark> petertodd: which one?
 56 2013-09-17 00:15:03 <Luke-Jr> for relaying, it makes sense to just rate limit and prioritise no-fee txns IMO
 57 2013-09-17 00:15:05 <gavinandresen> gmaxwell: mmm.  Random thought I had was:  if #outputs+1 > #inputs then NOTFREE.   But we'll hate that if we start creating multiple change outputs for privacy....
 58 2013-09-17 00:15:08 <Luke-Jr> for mining is another matter
 59 2013-09-17 00:15:27 <petertodd> CodeShark: it was at http://46.4.92.107:3191/, one of Amir's friends
 60 2013-09-17 00:15:40 <Luke-Jr> gavinandresen: I don't think we need multiple change outputs, if CoinJoin gets integrated.
 61 2013-09-17 00:15:48 <Belxjander> gmaxwell: clamp priority as a %? anything that is 100% gets queued and anything 99% and lower is delayed until fitted into a "batch" for each block?
 62 2013-09-17 00:16:10 <gmaxwell> gavinandresen: yea, and say you have 10 inputs, wouldn't you want to make there be 11 outputs, just so you have outputs to consume later to keep yourself under that rule?
 63 2013-09-17 00:16:17 <gmaxwell> Belxjander: clamping is exactly the problem.
 64 2013-09-17 00:16:47 <Luke-Jr> gmaxwell: 11+1 > 10 = true
 65 2013-09-17 00:16:52 <gmaxwell> Belxjander: the point I was making is that if your transaction is too good then you may add more outputs to make it worse in order to have yummy outputs to redeem later.
 66 2013-09-17 00:17:13 <gmaxwell> Luke-Jr: oops, fencepost error, 9  same point.
 67 2013-09-17 00:17:50 <gmaxwell> In any case, that weirdness goes away if you just make additional inputs nearly free (doesn't hurt your priority) but not less than free.
 68 2013-09-17 00:17:52 <CodeShark> petertodd: either the URL is bad or the server is down
 69 2013-09-17 00:17:55 <gavinandresen> gmaxwell: yes…  So, spam attack I'm worried about:  Person with 100 BTC decides to be an asshole.  Once a day they generate a high-priority transaction that splits of a bunch of DUST+1-sized outputs....
 70 2013-09-17 00:18:38 <petertodd> CodeShark: hence the "it was" :P got posted on Amir's unsystem mailing list, google it!
 71 2013-09-17 00:19:26 <gavinandresen> gmaxwell: perhaps priority should be calculated based on median txout size….
 72 2013-09-17 00:20:11 <gmaxwell> gavinandresen: yup, lots of total value, I'm not sure that it's really much of an attack though— those outputs need to get consumed someday, the attack was really in the creation of the outputs. The problem with it is that it may be rather 'lumpy' and use up all the space at once.
 73 2013-09-17 00:21:01 <gavinandresen> gmaxwell: right.  With planning, you could monopolize the free area
 74 2013-09-17 00:21:15 <gmaxwell> I could say "limit free txn to some sane size" but we actually do want to encourage people to sweep up their dust.
 75 2013-09-17 00:21:32 <Belxjander> gmaxwell: scale the difference of inputs and outputs and don't care how many or how much?
 76 2013-09-17 00:21:39 <gmaxwell> More ideally some "size limit depends on how old your inputs are" but thats too hard for people to reason about.
 77 2013-09-17 00:22:24 <gavinandresen> The behavior I want to disincentivize is creating lots of tiny txouts.
 78 2013-09-17 00:22:50 <gavinandresen> The dust rule goes a long way....
 79 2013-09-17 00:22:51 <petertodd> gmaxwell: It's notably that third-party wallets almost never try to take priority rules into account.
 80 2013-09-17 00:22:54 <gmaxwell> gavinandresen: e.g. right now you can easily find threads on the forum where people have dust filled wallets and they try to send from them and fail and eventually they export a single private key that has most of their funds and delete the wallet.
 81 2013-09-17 00:23:20 <gmaxwell> gavinandresen: right we do want to disincentivize creating them but also not disincentivize consuming them once they're created.
 82 2013-09-17 00:23:40 <gmaxwell> I don't think we can incentivize consuming them without also incentivizing creating them.
 83 2013-09-17 00:23:42 <sipa> Luke-Jr: last time i ask this (promised!), but how did you get the pull requests as a remote repo?
 84 2013-09-17 00:23:51 <gavinandresen> gmaxwell: right, which is why calculating priority based on the txout value(s) might make more sense than the txin value(s)
 85 2013-09-17 00:24:25 <warren> gavinandresen: one patch from litecoin will disincent the creation of lots of tiny txouts
 86 2013-09-17 00:24:32 <CodeShark> if the cost of creating them is larger than the reward of consuming them, doesn't that solve the issue?
 87 2013-09-17 00:24:33 <gavinandresen> gmaxwell: just brainstorming, but something like (weighted ages of txins) * (median value of txouts) ….
 88 2013-09-17 00:24:41 <warren> gavinandresen: asking people to "stop doing it" doens't work.
 89 2013-09-17 00:25:12 <gavinandresen> warren: what does litecoin do?  The base-fee-for-every-output-less-than-0.01?
 90 2013-09-17 00:25:21 <warren> gavinandresen: yes, since 2011
 91 2013-09-17 00:25:34 <gavinandresen> warren: I'm trying to get rid of hard-coded, centralized fee setting
 92 2013-09-17 00:25:49 <CodeShark> lower base fee for transactions that consume dust, increase base fee for transactions that create it
 93 2013-09-17 00:26:04 <warren> gavinandresen: it doesn't have to be hard-coded, it can be multiplicative of whatever the floating going rate is
 94 2013-09-17 00:26:08 <gavinandresen> CodeShark: I'm trying to get rid of hard-coded … yada yada
 95 2013-09-17 00:26:18 <gmaxwell> gavinandresen: for txouts, what you want is the harmonic mean I think.
 96 2013-09-17 00:28:06 <gmaxwell> Thats the canonical "small values dominate the result" function, it's also the case that the harmonic mean reflects the future bitcoin days destroyed per byte of the txn that would consume those outputs.
 97 2013-09-17 00:28:30 <gavinandresen> gmaxwell: that sounds right.  Looks easy to calculate....
 98 2013-09-17 00:28:39 <justusranvier> What if a transaction is always eilgible for relaying and block inclusion if the number txouts is less than the number of txins, regardless of other criteria?
 99 2013-09-17 00:29:19 <sipa> justusranvier: even if it is 500 KiB and pays no fees?
100 2013-09-17 00:29:25 <CodeShark> I still like the idea of charging rent for unspent outs (by the kb, not by the bitcoin - this is not demurrage) and deleting the unspent out when it can no longer afford to pay the rent :)
101 2013-09-17 00:29:48 <sipa> who sets the fee/kb?
102 2013-09-17 00:29:58 <gmaxwell> CodeShark: I know, but it's an economic change, a non-trivial one— and worse, it has parameters.
103 2013-09-17 00:30:23 <CodeShark> there are many issues that would need to be solved - it's far from trivial. but I like it in principle :)
104 2013-09-17 00:30:59 <gmaxwell> If satoshi had set that in at the outset there would be a good probablity that the parmeters would turn out wrong... we're lucky with most of the ones we have... but at least even that wouldn't have the consent problem.
105 2013-09-17 00:31:37 <gmaxwell> For a brief moment I'd hoped people would consent to such a change without trouble, but no, actually turns out that a lot of people are really hostile to the idea. I think most can be talked around to it with about an hour of 1:1 talk....
106 2013-09-17 00:32:20 <gavinandresen> sipa: I plan on asking miners/pools to set the minimum fee/kb that they'll include in blocks
107 2013-09-17 00:33:01 <sipa> gmaxwell: which idea?
108 2013-09-17 00:33:03 <gavinandresen> sipa: actually, that's a different topic:  I'm very tempted to FORCE miners to make that decision instead of relying on a default we set
109 2013-09-17 00:33:50 <sipa> gavinandresen: i wasn't talking about your plan (which i'm fuzzy about, i must admit), but who would set the rent price in codeshark's idea
110 2013-09-17 00:33:57 <gavinandresen> gmaxwell: did you see the estimate on the forums last year on transaction fee needed to be paid now to pay for a UTXO forever, assuming moore's law holds?
111 2013-09-17 00:34:23 <warren> gavinandresen: how will relays know whether or not a tx fee is high enough to relay?
112 2013-09-17 00:34:30 <warren> gavinandresen: they aren't privy to what miners chose
113 2013-09-17 00:34:42 <petertodd> warren: Sure they are: just watch what tx's get mined.
114 2013-09-17 00:35:02 <gavinandresen> warren: see https://gist.github.com/gavinandresen/6548612   -- they'll watch what miners decide to include
115 2013-09-17 00:35:04 <petertodd> warren: Set a bandwidth limit and prioritize by fee.
116 2013-09-17 00:35:05 <sipa> or rather, which don't get mined
117 2013-09-17 00:35:10 <warren> I was told that was a bad idea because pools have side-contracts to mine stuff....
118 2013-09-17 00:35:12 <gmaxwell> gavinandresen: if I didn't see that one, I've seen some other (or done the same calculation myself)
119 2013-09-17 00:35:13 <petertodd> sipa: correct
120 2013-09-17 00:35:19 <gmaxwell> sipa: the expiration of utxo.
121 2013-09-17 00:35:35 <gmaxwell> It has motivations other than rent, e.g. uncertanty about the currency supply.
122 2013-09-17 00:35:48 <petertodd> warren: the side-contract stuff won't show up in mempools though - the rule is only if mempool -> block happens (or nothing happens)
123 2013-09-17 00:36:00 <warren> ah, ok
124 2013-09-17 00:36:06 <gavinandresen> sipa:  I've been running experiments on watching what DOES get mined, and it works well to estimate the miner's collective policies.
125 2013-09-17 00:36:19 <sipa> you can have a side-contract for things which are in mempools
126 2013-09-17 00:36:31 <sipa> resulting in skewed statistics
127 2013-09-17 00:36:35 <sipa> gavinandresen: ok, interesting
128 2013-09-17 00:36:47 <petertodd> warren: The ugly one is I've got a possible system that would keep rough balance sheets so you could aggregate micropayments to get tx's mined - but that can probably be a separate relaying network anyway.
129 2013-09-17 00:36:49 <sipa> but what advantage does that have over watching what doesn't get mined?
130 2013-09-17 00:37:16 <gavinandresen> sipa: you don't want to relay what does not get mined
131 2013-09-17 00:37:23 <gavinandresen> sipa:  … and if it is not relayed, then you don't see it.
132 2013-09-17 00:37:49 <gavinandresen> (so you don't get enough data to make a good estimate)
133 2013-09-17 00:37:50 <petertodd> warren: Main use there would be payment protocol, where the customer didn't add a fee, but you don't want to spend a fee uselessly in a child-pays-for-parent.
134 2013-09-17 00:38:28 <gavinandresen> (bah, just fell into one of my pet peeves:  "You only want to relay what has a good chance of being mined")
135 2013-09-17 00:38:41 <gavinandresen> (pet peeve == double negatives)
136 2013-09-17 00:39:08 <gmaxwell> gavinandresen: sure, but what you really want is the data from the most attractive transaction which failed to get mined, thats the one you have to beat.
137 2013-09-17 00:39:21 <gmaxwell> so you don't need the deep-pool of non-mined stuff.
138 2013-09-17 00:39:37 <gavinandresen> gmaxwell: "patches welcome"
139 2013-09-17 00:39:38 <sipa> gavinandresen: if "good chance" is 50%, being you relay everything which seems to be above 1/2 the priority that you think is needed for mining, you should get a very good view on the non-mined half
140 2013-09-17 00:39:49 <sipa> i have no data though, and i may be wrong
141 2013-09-17 00:40:09 <sipa> but that does seem much more robust to me
142 2013-09-17 00:40:39 <petertodd> See, I think that's all wrong: have users set a bandwidth limit, and prioritize within that limit. With node-to-node encryption if there's just junk that just means timing analysis was made harder. (but that's a big patch...)
143 2013-09-17 00:40:52 <CodeShark> sipa: the price per kb would have to be calculated from the total size of the utxo set and perhaps collected each block
144 2013-09-17 00:41:16 <gavinandresen> sipa:  I'll think on that.  In any case, I'd like to come to a resolution on how to compute priorities....
145 2013-09-17 00:41:39 <CodeShark> there are a couple other factors, too
146 2013-09-17 00:41:54 <sipa> 
ACTION zZzZ

147 2013-09-17 00:42:08 <CodeShark> sipa.sleep(5000)
148 2013-09-17 00:42:27 <gavinandresen> petertodd: So transaction limit is X.  You can choose either a free, high-priority transaction or a marginal fee-paying transactions……  which is chosen?
149 2013-09-17 00:42:37 <gavinandresen> (limit == bandwidth limit)
150 2013-09-17 00:42:50 <Luke-Jr> sipa: .git/config
151 2013-09-17 00:42:58 <Luke-Jr> [remote "origin-pull"]
152 2013-09-17 00:43:00 <Luke-Jr>     fetch = +refs/pull/*:refs/remotes/origin-pull/*
153 2013-09-17 00:43:01 <Luke-Jr>     url = git://github.com/bitcoin/bitcoin.git
154 2013-09-17 00:43:05 <gavinandresen> "get rid of free transactions" is not a good answer.
155 2013-09-17 00:43:10 <petertodd> gavinandresen: fee-paying of course - frankly I think working on priority code will very soon be a waste of time. But to the relay node they don't really care.
156 2013-09-17 00:43:32 <warren> Luke-Jr: it turns out you don't need a separate remote for that, you can add it as another fetch to origin
157 2013-09-17 00:43:49 <Luke-Jr> warren: perhaps; I prefer a separate remote
158 2013-09-17 00:43:52 <warren> k
159 2013-09-17 00:43:55 <Luke-Jr> I only fetch it when rebuilding next-test really
160 2013-09-17 00:44:05 <Luke-Jr> or at least when I'm prepared to update my next-test plan file
161 2013-09-17 00:44:08 <CodeShark> the number of bitcoins sent in the block, the number of transactions in the block, the current size of the utxo
162 2013-09-17 00:44:34 <petertodd> gavinandresen: For a relay node, it's not crazy to just do a direct priority -> fee conversion, penalizing tx's that make the utxo space bigger. (just mesure it per byte)
163 2013-09-17 00:45:13 <CodeShark> or not the number of transactions in the block - the total size of the block (in bytes)
164 2013-09-17 00:45:47 <petertodd> CodeShark: ?
165 2013-09-17 00:46:03 <CodeShark> the parameters that go into the formula for price per byte
166 2013-09-17 00:46:56 <CodeShark> and from an economic perspective, it seems to make sense that you buy real estate in blocks but rent utxo space
167 2013-09-17 00:47:05 <petertodd> CodeShark: yup
168 2013-09-17 00:47:12 <petertodd> CodeShark: but that's -wizards sadly
169 2013-09-17 00:48:38 <petertodd> Anyway, main thing is for now we need priority because we can't group tx's together for relaying.
170 2013-09-17 00:49:15 <gavinandresen> gmaxwell: I think I like  priority = sum(txin value*age) * harmonic_mean(txouts) / (adjusted size)     where adjusted size is your pull request
171 2013-09-17 00:49:31 <gavinandresen> oh, and harmonic_mean(txouts) is txout values
172 2013-09-17 00:51:34 <gmaxwell> (harmonic_mean(txouts) + fees) perhaps?
173 2013-09-17 00:52:01 <sipa> this seems quadratic in total value transacted
174 2013-09-17 00:52:05 <gmaxwell> (including a small fee shouldn't lower your priority)
175 2013-09-17 00:52:53 <gavinandresen> sipa: hmm?
176 2013-09-17 00:53:09 <sipa> gavinandresen: double all amounts (inputs and outputs), and the priority goes *4
177 2013-09-17 00:53:31 <gmaxwell> yea, the non-linearity in value isn't quite right.   (harmonic_mean(txouts)+fees)*(sum(txin value*age)/sum(txin value)) / (adjusted size)
178 2013-09-17 00:54:01 <CodeShark> wouldn't increasing the minimum fee for greater age effectively amount to charging rent?
179 2013-09-17 00:54:01 <gmaxwell> that basically computes an input weighed age and multiplies the harmonic mean by it?
180 2013-09-17 00:54:25 <petertodd> CodeShark: there's no such thing as a minimum fee
181 2013-09-17 00:54:35 <CodeShark> not as part of the protocol, sure
182 2013-09-17 00:54:37 <gmaxwell> CodeShark: and we are _decreasing_ the fee for greater age.
183 2013-09-17 00:54:39 <sipa> CodeShark: the problem is that if the rent because large enough, people will just leave it unspent
184 2013-09-17 00:54:58 <sipa> CodeShark: which is what you want to avoid at all costs
185 2013-09-17 00:55:04 <petertodd> CodeShark: rent works only if the txout can go bankrupt and vanish :P
186 2013-09-17 00:55:06 <CodeShark> sipa: right - they would also need to expire at some point
187 2013-09-17 00:55:09 <denisx> what happens when I use the checkpoints=0 option?
188 2013-09-17 00:55:20 <sipa> denisx: every signature will be checked
189 2013-09-17 00:55:23 <petertodd> CodeShark: ...and expiring is -wizards material
190 2013-09-17 00:55:28 <CodeShark> lol
191 2013-09-17 00:55:40 <denisx> sipa: how can have it the other way?
192 2013-09-17 00:55:41 <sipa> CodeShark: yeah, combined with some expiration, that makes perfect sense
193 2013-09-17 00:55:45 <gavinandresen> gmaxwell sipa: ACK, a division by sum(txin) is in order
194 2013-09-17 00:55:45 <sipa> denisx: ?
195 2013-09-17 00:55:51 <denisx> is there a way to set the checkpoint manually?
196 2013-09-17 00:55:56 <sipa> no
197 2013-09-17 00:55:59 <denisx> except in source
198 2013-09-17 00:56:15 <gmaxwell> denisx: what are you trying to accomplish?
199 2013-09-17 00:56:27 <sipa> 
ACTION guesses: avoiding all signature checks

200 2013-09-17 00:56:51 <CodeShark> why is adding expiration -wizards material?
201 2013-09-17 00:56:52 <petertodd> CodeShark: remember that with all this stuff basically we're saying "miners are still irrational, and people donate to the network, so lets figure out how to take advantage of that while we still can while the block subsidy dwarfs everything else"
202 2013-09-17 00:56:56 <denisx> I had a db corruption and deleted the chainstate
203 2013-09-17 00:57:00 <petertodd> CodeShark: it's an economic change
204 2013-09-17 00:57:13 <denisx> until the checkpoint it rebuilded fast, but now it crawls
205 2013-09-17 00:57:31 <gmaxwell> denisx: what kind of cpu?
206 2013-09-17 00:57:40 <denisx> i3
207 2013-09-17 00:58:29 <sipa> 
ACTION hopes to get rid of checkpoints altogether

208 2013-09-17 00:58:31 <gmaxwell> hm. how many cores and what clock? I'm surprised anything modern would be slow enough that you'd show up looking to disable it.
209 2013-09-17 00:58:36 <gavinandresen> CodeShark: … and it ain't gonna happen. Those 2-satoshi outputs you want to expire "might be worth thousands of dollars someday!"
210 2013-09-17 00:58:50 <gmaxwell> Yea, I fully expect that once headers first is merged we can at least reduce the importance of checkpoints.
211 2013-09-17 00:59:42 <gmaxwell> I'd also like to rename them to the extent that we keep them, because in altcoin land they now mean alerts that pick the winning chain...
212 2013-09-17 01:00:05 <denisx> gmaxwell: i3 3.2GHz, 1 package(s) x 2 core(s) x 2 SMT threads
213 2013-09-17 01:00:21 <CodeShark> full headers + sliding window for full validation seems like a reasonable approach
214 2013-09-17 01:00:23 <sipa> gmaxwell: what would you rename them to?
215 2013-09-17 01:00:30 <gmaxwell> sipa: chain pinning?
216 2013-09-17 01:00:38 <warren> gmaxwell: historicguideposts?
217 2013-09-17 01:00:49 <gmaxwell> sipa: "pinned block"
218 2013-09-17 01:00:57 <gmaxwell> I dunno, never actually thought of it.
219 2013-09-17 01:01:49 <sipa> wait, i was going to sleep?
220 2013-09-17 01:02:02 <sipa> 
ACTION goes into standby

221 2013-09-17 01:02:35 <gmaxwell> I'd prefer to remove them completely, since headers first based validation gating removes their pratical purpose... but I think people are too used to the security blank of them being the easy out explination as to why a chain rewrite from start can't happen.
222 2013-09-17 01:03:28 <petertodd> gmaxwell: Just don't update them and see how long it takes for people to realize that a 6 month old checkpoint is old enough that a rewrite would be a disaster anyway.
223 2013-09-17 01:04:55 <warren> I recognize https://github.com/bitcoin/bitcoin/pull/2910 is less important with headers first, but will it be of any benefit at all?
224 2013-09-17 01:05:41 <gmaxwell> petertodd: a one day rewrite would be a disaster.
225 2013-09-17 01:05:58 <CodeShark> http://jenkins.bluematt.me/pull-tester/2e9f1aca7a493f9eb82bdcfe38f47043e338ef24/test.log -  echo error: could not build paymentrequest.pb.h
226 2013-09-17 01:06:05 <petertodd> gmaxwell: Exactly!
227 2013-09-17 01:06:08 <gmaxwell> Certantly a multiday one. Thats why checkpoints aren't a real genuine and honest answer to that concern.
228 2013-09-17 01:06:47 <gmaxwell> But people like to fixate on the doomsday and checkpoints let you say "thats actually impossible", ... and for some weird reason that actually stops the questioning down that road, as if it were an actual answer!
229 2013-09-17 01:06:56 <gmaxwell> I'm guilty of using it myself, it's very effective.
230 2013-09-17 01:07:06 <Diablo-D3> gmaxwell: oh dude
231 2013-09-17 01:07:08 <Diablo-D3> Im the opposite
232 2013-09-17 01:07:19 <Diablo-D3> if someone tells me thats impossible
233 2013-09-17 01:07:23 <Diablo-D3> im like
234 2013-09-17 01:07:23 <gmaxwell> The downside is that then people also walk away thinking that checkpoints are the real consensus mechenism, and you can see a couple academic papers basically working under this perspective. :(
235 2013-09-17 01:07:27 <Diablo-D3> challangeaccepted.jpg
236 2013-09-17 01:07:47 <CodeShark> checkpoints could be hashed into block headers :)
237 2013-09-17 01:07:54 <sipa> CodeShark: LOL
238 2013-09-17 01:07:58 <petertodd> gmaxwell: ...and bitcoinmagazine reporting about feathercoins advanced checkpointing technology :/
239 2013-09-17 01:08:01 <CodeShark> hehe
240 2013-09-17 01:08:04 <Diablo-D3> CodeShark: hah
241 2013-09-17 01:08:06 <gmaxwell> Diablo-D3: but it really is impossible, but it was an irrelevant attack.  Someone said "what if I set this straw man on fire" and I responded "our strawmen are actually made of asbestos"
242 2013-09-17 01:08:09 <sipa> warren: i need to response to that
243 2013-09-17 01:08:18 <sipa> *respond
244 2013-09-17 01:08:19 <Diablo-D3> gmaxwell: lol
245 2013-09-17 01:08:38 <Diablo-D3> gmaxwell: seriously though, whats so big about the checkpoints?
246 2013-09-17 01:08:45 <warren> sipa: sorry, sleep
247 2013-09-17 01:08:50 <sipa> right!
248 2013-09-17 01:08:51 <Diablo-D3> its just there to prevent long term bullshit attacks against new clients
249 2013-09-17 01:08:52 <gmaxwell> sipa: bad sipa. sleep!
250 2013-09-17 01:09:02 <gmaxwell> Diablo-D3: yea, and headers first will do that a better way.
251 2013-09-17 01:09:02 <sipa> why are you all awake at such ungodly hours? :(
252 2013-09-17 01:09:03 <petertodd>  /ignore sipa ; sleep 8 hr ; /unignore sipa
253 2013-09-17 01:09:06 <CodeShark> sipa.notify_all();
254 2013-09-17 01:09:18 <Diablo-D3> gmaxwell: actually, why arent we already doing headers first
255 2013-09-17 01:09:21 <denisx> its only 3am here
256 2013-09-17 01:09:26 <denisx> too early ;)
257 2013-09-17 01:09:27 <gmaxwell> Because the code isn't done yet.
258 2013-09-17 01:09:30 <Diablo-D3> gmaxwell: I swear I asked that like 2 years ago and no one answered it
259 2013-09-17 01:09:51 <sipa> Diablo-D3: https://github.com/bitcoin/bitcoin/pull/2964. Done.
260 2013-09-17 01:10:07 <gmaxwell> Diablo-D3: and it's taken that time to move things to a point where doing it isn't terribly hard, and now its almost done.
261 2013-09-17 01:10:25 <Diablo-D3> gmaxwell: yay
262 2013-09-17 01:10:37 <sipa> only need to fix pulltester :(
263 2013-09-17 01:10:40 <Diablo-D3> also wtf, we're already on 0.8.5
264 2013-09-17 01:10:45 <sipa> (well, hopefully *only*)
265 2013-09-17 01:10:49 <cfields> CodeShark: that's no real error, the line just isn't silenced properly.
266 2013-09-17 01:10:54 <petertodd> sipa: go away :P
267 2013-09-17 01:10:59 <Diablo-D3> sipa: sleep dude
268 2013-09-17 01:11:05 <sipa> yes, moms
269 2013-09-17 01:11:12 <Diablo-D3> sipa: a healthy person needs at least 9 hours of sleep a night
270 2013-09-17 01:11:20 <cfields> CodeShark: it's "make paymentrequest.pb.h || echo echo error: could not build paymentrequest.pb.h"
271 2013-09-17 01:11:41 <gmaxwell> There are basically two pratical uses of checkpoints: closing off a bunch of stupid new-node DOS attacks, and the performance optimizations for the deep chain. Headers first can solve both.
272 2013-09-17 01:11:49 <CodeShark> ok
273 2013-09-17 01:12:20 <gmaxwell>  /nick sipas_mom01
274 2013-09-17 01:12:42 <petertodd> 
ACTION is a lumberjack and he's ok

275 2013-09-17 01:14:54 <petertodd> gmaxwell: What's the deal with the edge cases you and s-i-p-a were talking about re: headers first? Like three competing forks?
276 2013-09-17 01:18:06 <gmaxwell> it's fine, I think.
277 2013-09-17 01:18:31 <petertodd> cool, so nothing too unobvious then?
278 2013-09-17 01:18:34 <gmaxwell> I suggested a decision criteria, and for a bit he was thinking that it wasn't unique but I think he then realized he was confused.
279 2013-09-17 01:19:17 <petertodd> huh, though first you hear about is fine still right?
280 2013-09-17 01:19:19 <Diablo-D3> gmaxwell: so, just to be clear, headers first spams the 80 byte headers?
281 2013-09-17 01:19:24 <gmaxwell> basically, to get the right behavior you need to have the first-best made explicit.
282 2013-09-17 01:19:40 <petertodd> Right
283 2013-09-17 01:20:16 <gmaxwell> petertodd: the problem is that in the current code if you get a better set of headers and its invalid you'll be on the wrong chain.
284 2013-09-17 01:20:39 <petertodd> I'm working on doing a BlockChainHeaders class for python-bitcoinlib, and I figured I'd just go for headers first basically as step 1
285 2013-09-17 01:20:42 <gmaxwell> e.g.  A vs A' and you are on A and then you get A'-B but B is invalid.
286 2013-09-17 01:20:56 <CodeShark> gmaxwell: there's still an economic motivation NOT to create longer invalid chains
287 2013-09-17 01:21:06 <petertodd> gmaxwell: Right, so when you find out B is invalid, you need to backtrack?
288 2013-09-17 01:21:26 <CodeShark> creating longer chains is expensive
289 2013-09-17 01:21:37 <CodeShark> and carries huge risk of having all rewards voided
290 2013-09-17 01:21:44 <gmaxwell> CodeShark: until you can short bitcoin.
291 2013-09-17 01:22:08 <petertodd> CodeShark: problem is usually even if you don't know the full block yet the probability is very high it is a valid block, so you might as well start extending it
292 2013-09-17 01:22:15 <CodeShark> granted, an entity with sufficient resources and motivation to destroy bitcoin could mount such an attack
293 2013-09-17 01:22:53 <CodeShark> petertodd: yeah, there's also the issue of whether miners do full validation or not
294 2013-09-17 01:23:15 <petertodd> CodeShark: Nothing actually requires them too - I could easily run a SPV miner and get away with it.
295 2013-09-17 01:23:24 <petertodd> CodeShark: Kinda dangerous re: p2pool really.
296 2013-09-17 01:23:59 <gmaxwell> petertodd: Second largest public pool effectively was.
297 2013-09-17 01:24:09 <petertodd> gmaxwell: yup
298 2013-09-17 01:24:14 <gmaxwell> (50BTC and their P2SH orphaning debacle)
299 2013-09-17 01:25:25 <petertodd> I've been trying to figure out how to make miners prove they actually have complete UTXO sets (fairly easy) and working validation machinery. (probably impossible)
300 2013-09-17 01:26:30 <CodeShark> the problem is that verifying the miner has working validation machinery is probably at least as expensive as validating it yourself
301 2013-09-17 01:27:08 <petertodd> CodeShark: Nah, it's worse than that: there's no way to know it's bug free.
302 2013-09-17 01:27:37 <gmaxwell> CodeShark: it's not a replacement for validating it yourself. Thats not why you demand it from them, it's something all full nodes should demand of each other as an anti-defection proof.
303 2013-09-17 01:27:39 <CodeShark> petertodd: right - at best you could infer it's correct from past behavior but doesn't guarantee correct future behavior
304 2013-09-17 01:27:41 <petertodd> CodeShark: UTXO set though is just a NI proof-of-posession, although a good one is kinda bulky. :(*
305 2013-09-17 01:28:03 <gmaxwell> "E.g. since I'm doing all this annoying work, I darn well want to be sure all of you are too"
306 2013-09-17 01:28:13 <petertodd> gmaxwell: very good way of putting it
307 2013-09-17 01:28:46 <CodeShark> so there is built-in incentive for miners to validate - but no absolute guarantee
308 2013-09-17 01:28:47 <petertodd> gmaxwell: Oh, and that's what's interesting about fidelity bonded mining: it can be profitable to fool your buggy peers into producing invalid blocks.
309 2013-09-17 01:29:08 <CodeShark> perhaps the greatest risk would come from a bug in an implementation
310 2013-09-17 01:29:28 <petertodd> CodeShark: of course, that's a network-wide disaster
311 2013-09-17 01:29:47 <gmaxwell> esp wrt miners, since mining is competitive, you can reduce costs == more profit. At least thats a risk if validation cost is non-trivial (and maybe it already is, though I think it's nuts to say that)
312 2013-09-17 01:30:46 <petertodd> gmaxwell: It'll be interesting as margins go down and people start caring more about pool fees: they'll start wanting to use p2pool, but not wanting to store this big UTXO set and spend a bunch of time downloading crap.
313 2013-09-17 01:30:55 <petertodd> gmaxwell: hence SPV mode mining
314 2013-09-17 01:31:34 <gmaxwell> at least p2pool can prevent that.
315 2013-09-17 01:31:50 <gmaxwell> but not all ideas for decenteralized mining could.
316 2013-09-17 01:31:57 <petertodd> gmaxwell: yeah, it can easily bolt on proof-of-utxo unlike us
317 2013-09-17 01:32:03 <gmaxwell> right.
318 2013-09-17 01:32:47 <petertodd> gmaxwell: right now it doesn't really try to verify anything about mined blocks, though it at least directs a super-portion of the subsidy to the finder
319 2013-09-17 01:33:10 <gmaxwell> petertodd: IIRC it checks the basic stuff.
320 2013-09-17 01:33:16 <gmaxwell> e.g. headers level consistency.
321 2013-09-17 01:33:46 <petertodd> yeah, but it doesn't for instance check transactions (it used to penalize shares with tx's not in your mempool, but that was dropped)
322 2013-09-17 01:34:17 <gmaxwell> I'm pretty sure it never did that.
323 2013-09-17 01:34:32 <gmaxwell> It requires you to pre-relay your txn ahead of your shares, however.
324 2013-09-17 01:34:37 <petertodd> gmaxwell: Maybe I misread it, but something along those lines changed recently.
325 2013-09-17 01:38:50 <CodeShark> what's with these errors? http://jenkins.bluematt.me/pull-tester/962a3956d322c8558a43beec33ab1d3298f98458/test.log
326 2013-09-17 01:39:51 <gmaxwell> out of space in /tmp ?
327 2013-09-17 01:41:09 <CodeShark> 
ACTION invents a way to upload more disk space over a network

328 2013-09-17 01:45:49 <phantomcircuit> CodeShark, it's probably a tmpfs
329 2013-09-17 01:53:07 <cfields> CodeShark: mmm, that's a bit too coincidental considering the tests merge that just went in
330 2013-09-17 01:53:29 <CodeShark> cfields: care to elaborate?
331 2013-09-17 01:54:02 <cfields> CodeShark: current head of master: https://github.com/bitcoin/bitcoin/commit/b16e9f02c82b98635da53c7e485614cba766f0a9
332 2013-09-17 01:54:22 <CodeShark> oh, hmm - time for another rebase?
333 2013-09-17 01:55:17 <CodeShark> or the new merge just ate up all the disk space?
334 2013-09-17 01:55:57 <cfields> CodeShark: not quite sure. that merge causes the tests to be embedded into the binary rather than read from the .json files at runtime. shouldn't have any meaningful effect on size, really
335 2013-09-17 01:56:36 <cfields> CodeShark: i'm not sure how it'd be related. just pointing out the link between test failures and the last commit which changes how tests are run
336 2013-09-17 01:56:56 <CodeShark> but the last commit isn't a part of this particular test
337 2013-09-17 01:57:48 <cfields> pull-tester merges the test-branch into master before running, no?
338 2013-09-17 01:58:28 <CodeShark> I really don't know
339 2013-09-17 01:59:03 <cfields> i'll pull your branch and verify that i didn't mess you up
340 2013-09-17 01:59:16 <CodeShark> ok, cool
341 2013-09-17 02:00:32 <cfields> which branch is it?
342 2013-09-17 02:02:37 <CodeShark> noautofillkeypool
343 2013-09-17 02:03:21 <CodeShark> pull request 2841
344 2013-09-17 02:07:07 <cfields> CodeShark: ok, the tests fail here as well. and they also fail before that merge
345 2013-09-17 02:07:43 <CodeShark> hmmm
346 2013-09-17 02:08:02 <CodeShark> you also get BDB errors?
347 2013-09-17 02:08:21 <cfields> yea, same ones
348 2013-09-17 02:08:38 <CodeShark> or I mean CDB
349 2013-09-17 02:09:17 <cfields> CodeShark: heh, same errors just building your branch as well :)
350 2013-09-17 02:11:04 <cfields> CodeShark: 'make check' is clean for you?
351 2013-09-17 02:11:29 <CodeShark> no
352 2013-09-17 02:11:35 <CodeShark> I get those CDB errors
353 2013-09-17 02:11:43 <CodeShark> and the SSL errors, too
354 2013-09-17 02:13:40 <CodeShark> bitcoind and bitcoin-qt seem to run fine, though
355 2013-09-17 02:31:09 <CodeShark> oh, I think I know what might be going on
356 2013-09-17 02:31:34 <CodeShark> I removed the default key from the wallet
357 2013-09-17 02:33:46 <CodeShark> the best fix is probably to just fill the key pool when the wallet is initially created
358 2013-09-17 02:35:57 <gmaxwell> CodeShark: I thought we fixed missing a default key for the locked salvagewallet case?
359 2013-09-17 02:36:56 <CodeShark> no, I mean I removed default key support from the codebase
360 2013-09-17 02:37:17 <CodeShark> not from wallet.dat
361 2013-09-17 02:39:03 <CodeShark> err
362 2013-09-17 02:39:12 <hydromet> does anyone have any recommendations for exchanging fiat for BTC (especially for Americans wanting to exchange USD)?
363 2013-09-17 02:39:17 <CodeShark> actually, scratch that - the issue is probably that the wallet is empty when it is first created
364 2013-09-17 02:39:20 <hydromet> given the problems Mt. Gox has endured ....
365 2013-09-17 02:39:40 <CodeShark> there's also bitstamp
366 2013-09-17 02:39:45 <CodeShark> and a few smaller exchanges
367 2013-09-17 02:39:55 <gmaxwell> hydromet: wrong channel for that question, fwiw.
368 2013-09-17 02:40:09 <CodeShark> but yeah, try #bitcoin-otc
369 2013-09-17 02:40:52 <hydromet> gmaxwell: yes and no fwiw ... after all the work getting Bitcoin-Qt to build from source from master with autotools on OS X, the wallet should be used including for receiving the egress of exchanges from fiat
370 2013-09-17 02:41:24 <CodeShark> ???
371 2013-09-17 02:41:49 <hydromet> gmaxwell: but I do agree there are probably better channels to ask this sort of question since this channel is devoted more so to development
372 2013-09-17 02:42:47 <hydromet> CodeShark: jumped through hoops this past weekend to get Bitcoin-Qt from master to compile on OS X with intricate dependency challenged including libtiff believe it or not
373 2013-09-17 02:42:56 <hydromet> challengees
374 2013-09-17 02:43:01 <hydromet> can't spell today
375 2013-09-17 02:43:33 <CodeShark> that wasn't the part of your comment for which I typed ???
376 2013-09-17 02:43:40 <CodeShark> it's the second part
377 2013-09-17 02:44:15 <CodeShark> the part after the comma
378 2013-09-17 02:44:51 <hydromet> speaking of wallets, interesting news today about Bitcoin Wallet Armory raising money today to develop its wallet further
379 2013-09-17 02:45:13 <hydromet> http://www.marketwatch.com/story/most-secure-bitcoin-wallet-armory-raises-600k-led-by-trace-mayer-2013-09-16
380 2013-09-17 02:45:31 <CodeShark> good luck to alan
381 2013-09-17 02:45:41 <hydromet> indeed
382 2013-09-17 02:46:32 <hydromet> they'll have three full timers on armory ... should be interesting
383 2013-09-17 02:47:09 <gmaxwell> I still don't understand how they're planning on making money.
384 2013-09-17 02:47:32 <hydromet> they don't seem to know the answer to that question yet
385 2013-09-17 02:47:33 <gmaxwell> (I don't mean that in a negative light or anything)
386 2013-09-17 02:48:04 <gmaxwell> I talked to alan about his business plans at the conference (was kinda odd that armory had a booth…) and he gave an answer that I must not have really understood.
387 2013-09-17 02:48:04 <hydromet> it strikes me as one of those "we'll figure it out later" scenarios
388 2013-09-17 02:48:41 <gmaxwell> He's a really smart dude so I'm sure he'll come out on top regardless of how it pans out.
389 2013-09-17 02:48:45 <hydromet> maybe alan had some ideas but didn't want to divulge?
390 2013-09-17 02:49:09 <Diablo-D3> I think what hydromet said is probably true
391 2013-09-17 02:50:23 <gmaxwell> Perhaps, though he could have also just told me that. Or maybe he was telling me that and I was too dense to hear it. :) Always possible.
392 2013-09-17 02:50:42 <Diablo-D3> well
393 2013-09-17 02:50:45 <Diablo-D3> I dunno dude
394 2013-09-17 02:50:48 <Diablo-D3> you're pretty smart
395 2013-09-17 02:50:52 <Cusipzzz> 600k 600k doesn't last that long
396 2013-09-17 02:51:09 <gmaxwell> when you're employing multiple people, no...
397 2013-09-17 02:51:16 <Diablo-D3> otoh
398 2013-09-17 02:51:22 <Diablo-D3> I could make 600k last the rest of my life =/
399 2013-09-17 02:52:23 <gmaxwell> Diablo-D3: yea, just get a really good drug and skydiving habbit...
400 2013-09-17 02:52:25 <hydromet> overall this seems a good move for Bitcoin at large
401 2013-09-17 02:52:40 <Diablo-D3> gmaxwell: hah
402 2013-09-17 02:52:56 <gmaxwell> hydromet: well, if it goes kablooy and the end result is alan exiting, not so much.
403 2013-09-17 02:54:17 <hydromet> gmaxwell: its difficult to say since we don't know the terms and conditions negotiated between alan and the investors (i.e., exits)
404 2013-09-17 02:55:50 <Diablo-D3> http://sphia.org/index.html
405 2013-09-17 02:56:09 <Diablo-D3> time to replace leveldb
406 2013-09-17 02:56:09 <TheLordOfTime> ... I found an interesting bug... but i don't know how to test/replicate as it happens randomly...
407 2013-09-17 02:56:10 <Diablo-D3> 
ACTION runs

408 2013-09-17 02:56:20 <TheLordOfTime> occasionally, on Ubuntu/Linux, 0.8.5 won't load the bitcoin tray icon
409 2013-09-17 02:56:32 <TheLordOfTime> and this is with BlueMatt's PPAs
410 2013-09-17 03:16:32 <jgarzik> OSv: impressive stuff.  https://docs.google.com/presentation/d/11mxUl8PBDQ3C4QyeHBT8BcMPGzqk-C8bV1Fw8xLgwSI/edit#slide=id.ge6c9b92a_031
411 2013-09-17 03:16:42 <jgarzik> (even though I'm not a JVM fan)
412 2013-09-17 03:16:56 <jgarzik> A lot of solid, well known Linux kernel engineers attached
413 2013-09-17 03:20:58 <cfields> avi kivity is a big name indeed
414 2013-09-17 03:21:07 <Cusipzzz> cool deck
415 2013-09-17 03:21:14 <cfields> but jvm in-kernel...
416 2013-09-17 03:22:11 <jgarzik> netchannels is a big feature, though few outside TCP/IP geek circles know of it
417 2013-09-17 03:23:35 <jgarzik> design opens the possibility of beating just about every mainstream OS in terms of TCP/IP CPU usage.  No problem doing an X Gbps TCP/IP stream.
418 2013-09-17 03:23:38 <cfields> heh, porting native apps reads identically to porting android apps
419 2013-09-17 03:23:57 <cfields> and chrome's nativeclient stuff is starting to sound the same
420 2013-09-17 03:24:12 <cfields> shared libs: apps 2.0 !
421 2013-09-17 03:24:56 <jgarzik> They finally got rid of that pesky userland once and for all
422 2013-09-17 03:25:04 <jgarzik> ;p
423 2013-09-17 03:25:13 <cfields> heh, Linus' dream-come-true
424 2013-09-17 03:27:14 <cfields> that's pretty much how it reads, though. sandbox to kernel with almost nothing in between
425 2013-09-17 03:29:11 <cfields> jgarzik: never heard of netchannels. any suggested reading?
426 2013-09-17 03:32:59 <jgarzik> cfields, search string "van jacobson net channels"
427 2013-09-17 03:33:07 <jgarzik> without the quotes
428 2013-09-17 03:33:39 <cfields> thanks
429 2013-09-17 03:37:55 <jgarzik> Here's a good link: http://lwn.net/Articles/169961/    Moving a lot of the TCP/IP processing down into the end-of-line application has several efficiencies.
430 2013-09-17 03:44:08 <CodeShark> interesting. thanks, jgarzik
431 2013-09-17 03:51:58 <jgarzik> DaveM's blog post on net channels is also worth reading, if a bit more technical: http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27#vj_channels  DaveM is the kernel networking maintainer.
432 2013-09-17 03:52:06 <jgarzik> (also gcc on Sparc and glibc)
433 2013-09-17 04:48:24 <Krellan> Nice to read about "net channels".  I'm still waiting for Van Jacobsen to finish pathchar :)
434 2013-09-17 05:08:52 <swulf--> "Safe mode: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."
435 2013-09-17 05:08:59 <swulf--> what's the proper course of action to fix this?
436 2013-09-17 05:09:06 <CodeShark> -reindex
437 2013-09-17 05:09:12 <swulf--> ok
438 2013-09-17 05:09:18 <Luke-Jr> O.o
439 2013-09-17 05:09:26 <Luke-Jr> swulf--: depends on the cause
440 2013-09-17 05:09:35 <Luke-Jr> swulf--: what version is it?
441 2013-09-17 05:09:50 <swulf-->     "version" : 80300,
442 2013-09-17 05:10:10 <Luke-Jr> swulf--: upload your debug.log somewhere
443 2013-09-17 05:10:29 <Luke-Jr> share the link privately if you'd not want your transaction privacy compromised
444 2013-09-17 05:11:16 <Luke-Jr> it's probably big - please don't try to trim it
445 2013-09-17 05:11:27 <swulf--> hmmm, it doesn't look like there's any log info in there
446 2013-09-17 05:11:37 <Luke-Jr> :/
447 2013-09-17 05:11:37 <warren> what's all the config options to shrink memory of bitcoind as much as possible?
448 2013-09-17 05:11:43 <warren> maxconnections dbcache, what else?
449 2013-09-17 05:11:44 <swulf--> i use -printtoconsole - does that cause it to not log to debug.log too?
450 2013-09-17 05:11:52 <Luke-Jr> swulf--: probably
451 2013-09-17 05:12:32 <Luke-Jr> swulf--: well, -reindex should help in most cases; but upgrade to 0.8.5 first
452 2013-09-17 05:12:39 <swulf--> perhaps it should be renamed to -printtoconsoleaswell
453 2013-09-17 05:12:56 <swulf--> hehe..
454 2013-09-17 05:14:07 <Luke-Jr> that'd be the opposite!
455 2013-09-17 05:16:19 <swulf--> i'll start with my old blockchain download and see where that gets me
456 2013-09-17 05:16:45 <Luke-Jr> swulf--: ?
457 2013-09-17 05:21:34 <swulf--> i made a backup of the block index, so i just copy that over whenever a corruption occurs
458 2013-09-17 05:21:45 <swulf--> its roughly a week or two old so that's gonna be much faster than a -reinde
459 2013-09-17 05:21:46 <swulf--> x
460 2013-09-17 05:43:54 <Luke-Jr> swulf--: that's probably why it's broken
461 2013-09-17 07:09:30 <last1> I have a question regarding pushpoold. Is this the right place to ask ?
462 2013-09-17 07:10:11 <weex> last1: can't hurt
463 2013-09-17 07:11:11 <last1> I setup bitcoind, pushpool connects just fine to it. Now I also setup a frontend ( SimpleBTC ) but I get no stats in SimpleBTC
464 2013-09-17 07:11:25 <last1> the front requires a bitcoind RPC user/pass which I supplied so it connects directly there
465 2013-09-17 07:11:49 <last1> shouldn't it connect through pushpool in order to get the stats for all the accounts ?
466 2013-09-17 07:16:06 <Luke-Jr> last1: pushpool hasn't been maintained in years
467 2013-09-17 07:19:37 <last1> true, but I don't think that's the issue
468 2013-09-17 07:19:48 <last1> my question is more like: should the frontend really be talking directly to bitcoind ?
469 2013-09-17 07:19:58 <last1> shouldn't it be going through pushpoold instead ?
470 2013-09-17 07:28:22 <Luke-Jr> last1: I can't imagine why it would talk to pushpool
471 2013-09-17 07:28:58 <last1> well, how would it know then which account did what ?
472 2013-09-17 07:28:59 <Luke-Jr> last1: furthermore, pushpool isn't really workable for Bitcoin mining
473 2013-09-17 07:29:26 <Luke-Jr> it proxies the deprecated getwork protocol which bitcoind can't handle the load from for any significant mining
474 2013-09-17 07:29:37 <Luke-Jr> last1: pushpool logs shares to a SQL database usually
475 2013-09-17 07:30:01 <last1> but the miners connect to the pushpool open port
476 2013-09-17 07:30:09 <last1> not to bitcoind
477 2013-09-17 07:30:18 <Luke-Jr> pushpool is just a proxy.
478 2013-09-17 07:30:37 <last1> ok, so if user A proxies through pushpool to bitcoind
479 2013-09-17 07:30:49 <last1> can bitcoinD make the different between work done by user A and user B ?
480 2013-09-17 07:30:53 <Luke-Jr> nope
481 2013-09-17 07:31:15 <last1> so then how does the frontend know which user did what by talking to bitcoind ?
482 2013-09-17 07:31:21 <last1> it has to talk to pushpool (?)
483 2013-09-17 07:31:24 <Luke-Jr> it doesn't
484 2013-09-17 07:31:30 <Luke-Jr> it looks at the SQL database
485 2013-09-17 07:31:39 <last1> aaah
486 2013-09-17 07:31:44 <Luke-Jr> it talks to bitcoind for incidental network info probably
487 2013-09-17 07:31:48 <Luke-Jr> like difficulty
488 2013-09-17 07:32:20 <last1> well, in the frontend bitcoincontroller code I see stuff like this
489 2013-09-17 07:32:22 <last1> $this->query("getbalance", $account, $minconf);
490 2013-09-17 07:32:31 <last1> this is sent directly to the bitcoind daemon through RPC
491 2013-09-17 07:32:51 <Luke-Jr> you'd have to figure out who made SimpleBTC and ask them why they do that
492 2013-09-17 07:33:53 <last1> what would you recommend instead of pushpoold ?
493 2013-09-17 07:34:35 <Luke-Jr> last1: Eloipool (which I am the author of) is AFAIK the only maintained open source poolserver software
494 2013-09-17 07:34:45 <Luke-Jr> jgarzik was also writing one in C++, but I am not sure if it's complete
495 2013-09-17 07:35:16 <last1> understood. and which frontend works best with your software ?
496 2013-09-17 07:35:26 <Luke-Jr> I'm not familiar with any frontends.
497 2013-09-17 07:38:25 <last1> does eloipool support stratum ?
498 2013-09-17 07:41:25 <Luke-Jr> last1: yes
499 2013-09-17 07:41:35 <last1> how do you manage the miners/stats if there's no GUI ?
500 2013-09-17 07:47:18 <michagogo> 
ACTION guesses: the command line

501 2013-09-17 07:47:25 <michagogo> (or text files)
502 2013-09-17 08:29:02 <thermoman> is the noirc option still available in 0.8.5? what i want to say: are all options listed on ./bitcoind --help call?
503 2013-09-17 08:29:16 <thermoman> or are there more options that are not listed
504 2013-09-17 08:47:31 <sipa> mornin'
505 2013-09-17 08:50:25 <warren> sipa: so response? =)
506 2013-09-17 08:50:31 <warren> thermoman: there's no irc anymore
507 2013-09-17 08:52:27 <sipa> warren: ?
508 2013-09-17 08:52:36 <sipa> ah, on that pullreq
509 2013-09-17 09:02:37 <thermoman> i cleaned out some old config options from bitcoin.conf (like server=1, noirc=1) and now the 0.8.5 client dropped the chainstate and blockindex and does the import *again*
510 2013-09-17 09:02:40 <thermoman> why is this?
511 2013-09-17 09:03:45 <sipa> import from?
512 2013-09-17 09:05:08 <thermoman> sipa: the blkl*dat files
513 2013-09-17 09:06:58 <thermoman> sipa: i upgraded from 0.7.2 to 0.8.5 yesterday
514 2013-09-17 09:07:03 <thermoman> with unchanged bitcoin.conf
515 2013-09-17 09:07:13 <swulf--> LevelDB read failure: Corruption: block checksum mismatch
516 2013-09-17 09:07:15 <swulf--> yet again...
517 2013-09-17 09:07:15 <thermoman> stopped/started the 0.8.5 client several times
518 2013-09-17 09:07:47 <thermoman> and now it cleaned out the index and chainstate and does the migration again
519 2013-09-17 09:08:11 <sipa> did you start with -reindex ?
520 2013-09-17 09:08:31 <sipa> or with reindex=1 in tbe config file?
521 2013-09-17 09:09:18 <thermoman> ah fuck - i had -txindex=1 -reindex=1 -daemon options in it but no rpc ... started it ... so the client reported that i need to add rpcuser and rpcpassword and refused to start.
522 2013-09-17 09:09:27 <thermoman> then i deleted the -txindex=1 -reindex=1
523 2013-09-17 09:09:29 <thermoman> and started
524 2013-09-17 09:09:52 <thermoman> so i guess the -txindex=1 -reindex=1 call removed all the leveldb stuff even though the client didn't start up
525 2013-09-17 09:10:15 <sipa> -reindex means "rebuild the database"
526 2013-09-17 09:10:19 <thermoman> yes
527 2013-09-17 09:10:21 <thermoman> i understand
528 2013-09-17 09:10:41 <thermoman> i just didn't thought that the client would delete the database when it's not starting up
529 2013-09-17 09:11:17 <thermoman> i was under the impression all options would be parsed first and if an error occurs (like -daemon but no -rpc*) nothing is done
530 2013-09-17 09:11:26 <thermoman> seems i was wrong
531 2013-09-17 09:12:29 <thermoman> sipa: if i wanted -txindex=1 -reindex=1 ... would i have to start the daemon with these 2 options every time or only once?
532 2013-09-17 09:12:52 <sipa> you can set txindex every time, or just once
533 2013-09-17 09:13:09 <sipa> reindex should only be oassed once
534 2013-09-17 09:13:13 <sipa> *passed
535 2013-09-17 09:13:16 <thermoman> ok
536 2013-09-17 09:13:27 <thermoman> then the README file is not clear on this point
537 2013-09-17 09:13:38 <sipa> what does it say?
538 2013-09-17 09:13:41 <thermoman> it states one should add these two options to get the full stuff
539 2013-09-17 09:13:52 <thermoman> but it doesn't say to do the -reindex=1 only once
540 2013-09-17 09:14:07 <sipa> what file is that?
541 2013-09-17 09:14:19 <sipa> i didn't it was even mentioned in some documentation
542 2013-09-17 09:14:19 <thermoman> one moment
543 2013-09-17 09:14:25 <sipa> *even know
544 2013-09-17 09:14:28 <thermoman> http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.8.5/
545 2013-09-17 09:14:32 <thermoman> oops
546 2013-09-17 09:14:46 <thermoman> http://sourceforge.net/projects/bitcoin/files/http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/ete/bitcoin-0.8.5/
547 2013-09-17 09:14:49 <thermoman> damn
548 2013-09-17 09:14:51 <thermoman> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/
549 2013-09-17 09:15:03 <thermoman> wrong
550 2013-09-17 09:15:04 <thermoman> lemme check
551 2013-09-17 09:16:42 <thermoman> 0.8.0 Release notes
552 2013-09-17 09:16:47 <thermoman> http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.8.1/
553 2013-09-17 09:16:54 <thermoman> This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details).
554 2013-09-17 09:17:06 <thermoman> damn
555 2013-09-17 09:17:09 <thermoman> "once"
556 2013-09-17 09:17:13 <thermoman> i see
557 2013-09-17 09:17:18 <thermoman> sorry, sipa
558 2013-09-17 09:17:22 <sipa> :)
559 2013-09-17 09:17:30 <thermoman> ;)
560 2013-09-17 09:20:55 <thermoman> sipa: the wallet always gets synced upon exit, right? so i don't have to keep the database/ directory after a successfull shutdown, right?
561 2013-09-17 09:21:30 <sipa> the database/ directory should just be deleted at succesful shutdown, i think
562 2013-09-17 09:22:26 <nkuttler> can i run two nodes from the same datadir, one of them testnet?
563 2013-09-17 09:26:38 <thermoman> can bitcoind leverage sse support and such things?
564 2013-09-17 09:26:58 <sipa> thermoman: only a miner would benefit from that much
565 2013-09-17 09:27:10 <sipa> nkuttler: yes
566 2013-09-17 09:27:13 <thermoman> i run the migration in a virtual machine and the default virtual cpu has no such flags
567 2013-09-17 09:27:34 <sipa> afaik it doesn't use sse
568 2013-09-17 09:27:40 <thermoman> ok
569 2013-09-17 09:28:33 <thermoman> 11:07 < swulf--> LevelDB read failure: Corruption: block checksum mismatch
570 2013-09-17 09:28:47 <thermoman> is this something i should be worried about when switching from 0.7.x to 0.8.5?
571 2013-09-17 09:29:25 <sipa> we've seen corruption both with old and with new nodes
572 2013-09-17 09:29:29 <nkuttler> sipa: nice, ty
573 2013-09-17 09:29:33 <sipa> it manifests differently, though
574 2013-09-17 09:30:19 <thermoman> what about robustness? can leveldb survive a crash?
575 2013-09-17 09:30:27 <sipa> it definitely should
576 2013-09-17 09:30:36 <sipa> but it doesn't for everyone
577 2013-09-17 09:30:51 <thermoman> worst case? reindex for 2 hours?
578 2013-09-17 09:31:05 <sipa> i've personally never ever seen it corrupt on crash, and that is including pulling a power plug
579 2013-09-17 09:31:15 <sipa> but others see it fail every time pretty muh
580 2013-09-17 09:31:36 <sipa> reindex fixes everything yes
581 2013-09-17 09:32:07 <thermoman> shouldn't the client keep the rpc port closed until the reindex is done?
582 2013-09-17 09:32:24 <thermoman> 8332 is open on my box doing the reindex thing right now
583 2013-09-17 09:32:36 <sipa> no, it us functional
584 2013-09-17 09:32:39 <sipa> *is
585 2013-09-17 09:33:00 <thermoman> wasn't there a warning that rpc stuff shouldn't be used while the migration is ongoing?
586 2013-09-17 09:33:11 <sipa> depends for what
587 2013-09-17 09:33:17 <thermoman> i remember something like that
588 2013-09-17 09:33:48 <thermoman> there was some issues with a pool i remember when the chain fork happened
589 2013-09-17 09:34:06 <thermoman> he lost btc due to sending them to pool members
590 2013-09-17 09:34:18 <sipa> yes
591 2013-09-17 09:34:21 <thermoman> because the rpc did report wrong info due to the import not being done
592 2013-09-17 09:34:54 <sipa> sure, it's working its way through history
593 2013-09-17 09:35:46 <thermoman> that's why an option "deny-rpc-while-reindexing" would be handy
594 2013-09-17 09:36:30 <sipa> it may make sense to disable some rpcs while reindexing
595 2013-09-17 09:37:48 <michagogo> Doesn't it already do that for some?
596 2013-09-17 09:37:52 <michagogo> gbt, for example?
597 2013-09-17 09:38:28 <sipa> i think getwork and gtb are disabled already yes
598 2013-09-17 09:38:29 <sipa> gbt
599 2013-09-17 09:38:36 <michagogo> Or is that only during IBD?
600 2013-09-17 09:38:53 <sipa> they're considered equivalent in most places
601 2013-09-17 09:39:00 <michagogo> figured
602 2013-09-17 09:39:02 <sipa> not exactly sure though
603 2013-09-17 09:39:04 <michagogo> but wasn't sure
604 2013-09-17 09:39:49 <michagogo> Makes sense -- in either case, the node doesn't yet have a full picture of what's happening with the network
605 2013-09-17 09:40:55 <Coincidental> Hey all, I've been working on a Ruby implementation of BIP32 Hierarchical Deterministic Wallets and am about to release the gem.
606 2013-09-17 09:41:20 <Coincidental> I wanted to run it by you guys here to see if anyone has knowledge of BIP32 and could give it a onceover.
607 2013-09-17 09:41:29 <Coincidental> https://github.com/wink/money-tree
608 2013-09-17 09:41:36 <sipa> do you pass the test vectors? :)
609 2013-09-17 09:41:41 <Coincidental> Yes indeed.
610 2013-09-17 09:42:05 <Coincidental> 99.96% code coverage
611 2013-09-17 09:42:29 <sipa> hmm, what specifically isn't being tested?
612 2013-09-17 09:43:36 <Coincidental> testnet
613 2013-09-17 09:43:51 <sipa> irony :)
614 2013-09-17 09:44:05 <michagogo> Lol.
615 2013-09-17 09:44:29 <Coincidental> True =) But I'm not actually sending any messages to the network. This is just creating wallets and importing wallets.
616 2013-09-17 09:45:08 <michagogo> Well, adding testnet support is fairly trivial, no?
617 2013-09-17 09:45:14 <michagogo> Just use a different version byte.
618 2013-09-17 09:45:15 <Coincidental> (and exporting serialized keys, etc.)
619 2013-09-17 09:45:41 <Coincidental> The version byte for testnet is implemented, I just haven't gotten around to writing the test. I'll be sure to do it tomorrow.
620 2013-09-17 09:45:48 <michagogo> Ah
621 2013-09-17 09:46:13 <Coincidental> But mainly I'm looking for someone to read over my readme, and if you have ruby knowledge, at least make sure I'm doing things sanely.
622 2013-09-17 09:46:26 <Coincidental> I just don't want to put out an unsafe product.
623 2013-09-17 09:46:34 <Coincidental> And crypto is brand new to me.
624 2013-09-17 09:47:45 <michagogo> Are the bitcoin-list and -test mailing lists used?
625 2013-09-17 09:51:12 <Coincidental> Maybe I'll just post this on the bitcoin-development list, hopefully someone will take a look.
626 2013-09-17 09:52:37 <Coincidental> Although, sipa, you're my man since you gave that awesome talk at the Bitcoin conf on BIP32. =)
627 2013-09-17 09:55:16 <sipa> Coincidental: thanks :)
628 2013-09-17 09:55:28 <sipa> i know no ruby though
629 2013-09-17 09:56:29 <Coincidental> sipa, that's ok, I mainly want to make sure that my README is correct, because I try to explain BIP32 in depth to the layperson, and I'm not sure if I have all the details correct.
630 2013-09-17 12:03:02 <Avvy> Hi all.
631 2013-09-17 12:03:58 <Avvy> I'm trying to create a Bitcoin application that stores keypairs independently of the Bitcoin library I'm using... i.e. in a secure database, rather than a wallet.
632 2013-09-17 12:04:15 <Avvy> Looked at a few libraries for this... now currently looking at BitcoinJ.
633 2013-09-17 12:04:26 <TD> hi there
634 2013-09-17 12:04:29 <Avvy> Anyone else done something like this?
635 2013-09-17 12:04:51 <TD> yeah
636 2013-09-17 12:05:00 <TD> one guy is working on integrating bitcoinj with Trezor
637 2013-09-17 12:05:10 <TD> another guy is doing a project to store keys and do signing of txns in a yubikey neo
638 2013-09-17 12:05:19 <TD> (with bitcoinj again)
639 2013-09-17 12:05:32 <Avvy> Ok, looks like I'm on the right track with BitcoinJ....
640 2013-09-17 12:05:47 <Avvy> I briefly looked at BOP... but that seemed kinda not working?  Experience with that?
641 2013-09-17 12:05:49 <Diablo-D3> if only Avvy knew who he was talking to
642 2013-09-17 12:05:51 <Avvy> Bits of Proof
643 2013-09-17 12:05:59 <TD> i've not tried it. i'm not aware of any reports it doesn't work
644 2013-09-17 12:06:05 <TD> how do you mean it doesn't work?
645 2013-09-17 12:07:06 <Avvy> TD... "it doesn't work" is probably unfair... it might... it had little documentation, and had lots of various errors upon startup... it didn't seem robust and stable.  It might work if persisted with it.  BitcoinJ seemed to be better supported in the community.
646 2013-09-17 12:07:59 <TD> ok. fyi the BOP author accepts money in return for support, if you're in the kind of situation where that is reasonable. otherwise sure, go ahead and use bcj
647 2013-09-17 12:08:28 <TD> be aware that if you want to do server side stuff for lots and lots of users simultaneously though, the core Wallet class in bcj doesn't scale very well
648 2013-09-17 12:08:33 <TD> 
ACTION is unaware of any open source wallets that scale well

649 2013-09-17 12:08:57 <TD> if what you're thinking of is more an app that users download and run themselves, it can be appropriate though
650 2013-09-17 12:09:17 <Avvy> TD... that was my impression also.  I was considering wrapping BitcoinJ up, and running multiple instances of it... each with their own blockchain.... so it becomes a little bit more scalable that way.
651 2013-09-17 12:09:39 <Avvy> The idea I had was to create a wallet... import keys as I need them... do something... then remove the keys from the wallet.
652 2013-09-17 12:09:51 <Avvy> So the BitcoinJ service doesn't have access to all addresses.
653 2013-09-17 12:10:01 <Avvy> (And keys etc)
654 2013-09-17 12:10:26 <TD> if you want to do that you also need to insert/remove transactions as well, so the wallet knows what it can spend
655 2013-09-17 12:10:45 <TD> like i said, if you want to do that server side, it's more work because you need full random access to all transactions (or at least unspent outputs)
656 2013-09-17 12:11:21 <Avvy> TD, may I ask your involvement?  Are you a developer with BitcoinJ?
657 2013-09-17 12:11:26 <TD> i wrote most of it
658 2013-09-17 12:11:40 <Avvy> TD... would you be interested in paid work... if so, may we speak privately?
659 2013-09-17 12:11:47 <TD> i'm not available for paid work at the moment i'm afraid
660 2013-09-17 12:11:59 <Avvy> Fair enough.
661 2013-09-17 12:12:15 <TD> if you ask on the mailing list, perhaps someone there is
662 2013-09-17 12:12:31 <TD> you could also contact bitcoin solutions ltd. that's gary and jim. together they have some experience with bitcoinj and may accept paid contract work
663 2013-09-17 12:12:51 <TD> gary.rowe@bitcoin-solutions.co.uk
664 2013-09-17 12:12:55 <Avvy> Ok, I'll look them up.  I notice there is a comment in BitcoinJ that says...
665 2013-09-17 12:13:22 <Avvy> (sorry, looking)
666 2013-09-17 12:13:43 <Avvy> "Note that adding multiple wallets is not well tested!"
667 2013-09-17 12:13:59 <TD> indeed
668 2013-09-17 12:14:04 <Avvy> Is it not really feasible to have multiple wallets, all pointing to the same Blockchain?
669 2013-09-17 12:14:14 <Avvy> (Thanks for the email btw)
670 2013-09-17 12:14:47 <TD> it's feasible, but the unit tests don't cover that case. and there are some caveats. jim burton (also with bsol) wrote extra code to make multibit handle multiple wallets simultaneously but it was never contributed/merged back upstream
671 2013-09-17 12:15:13 <TD> the basic caveat is if you disconnect a wallet, then it obviously won't get updated from the block chain. when you reconnect it, the block chain won't be re-wound and re-scanned to cover the missing sections
672 2013-09-17 12:15:38 <TD> jim wrote a replay manager that handles that. alternatively of course, you can just run multiple instances of the library (so you get multiple blockchains and wallets together)
673 2013-09-17 12:16:13 <Avvy> Yes... I've been considering running multiple instances of the library for that purpose.
674 2013-09-17 12:16:15 <TD> alternatively, you can store transactions in an indexed database, and then use the Wallet independently, without having it talk to the network at all
675 2013-09-17 12:16:25 <TD> then you just use Wallet as a "bag of keys and transactions" which knows how to create spends
676 2013-09-17 12:16:53 <Avvy> Well, let me put the question to you another way...
677 2013-09-17 12:17:09 <Avvy> I want to create a Service... which handles everything to do with Bitcoin network interaction....