1 2013-01-05 09:25:37 <Pucilowski> What's a bitcoin client that does not enforce fees?
  2 2013-01-05 09:26:36 <petertodd> it's not the client that enforces fees, it's the network
  3 2013-01-05 09:27:14 <petertodd> your transactions won't get relayed if you don't pay whatever fees the standard client thinks you should
  4 2013-01-05 09:31:48 <Pucilowski> There are plenty of transactions with no fees that get confirmed
  5 2013-01-05 09:32:01 <Pucilowski> I'm looking for a client that will allow me to make those
  6 2013-01-05 09:39:40 <Jouke> not all transactions need fees
  7 2013-01-05 09:40:23 <stealth222> bitcoind has different policies for creating transactions and for relay. it's possible to modify it to use the relay policy for both
  8 2013-01-05 09:40:48 <Pucilowski> If I use bitcoind's via command line will I be able to set 0 fee?
  9 2013-01-05 09:41:22 <stealth222> you can use 0 fee as long as you follow the minimum fee rules
 10 2013-01-05 09:41:48 <stealth222> no outputs smaller than .01, transaction has to be no bigger than a certain size - I'd have to look to see exactly what
 11 2013-01-05 09:42:26 <stealth222> by no bigger I mean in kb
 12 2013-01-05 09:43:06 <Pucilowski> Isn't it up to pools/miners to enforce transaction fees?
 13 2013-01-05 09:43:16 <Pucilowski> minimum tx fees*
 14 2013-01-05 09:44:07 <stealth222> to an extent, yes. but nobody will relay a bunch of small amount, large size zero fee transactions because that would allow DoS
 15 2013-01-05 09:48:32 <Pucilowski> Is there a client that enforces no rules at all?
 16 2013-01-05 09:49:37 <stealth222> your best bet would be to adhere to the minimum fee relay policy since other wise it is unlikely your transaction will get relayed even if the client broadcasts it
 17 2013-01-05 09:50:14 <Pucilowski> that's not my concern, I just wanna be able to broadcast a transaction with no fee
 18 2013-01-05 09:51:11 <Jouke> I don't know if it will work in bitcoin-qt, but for bitcoind you can set "paytxfee = 0" in the config file.
 19 2013-01-05 09:51:36 <Pucilowski> I'll play around with that, thanks Jouke
 20 2013-01-05 09:51:41 <stealth222> there's still a minimum fee for transactions that have very tiny outputs or are above a certain kb, Jouke
 21 2013-01-05 09:52:54 <Jouke> stealth222: it will enforce that fee even if you set the paytxfee?
 22 2013-01-05 09:53:06 <stealth222> I believe so, yes
 23 2013-01-05 09:53:12 <stealth222> look at CTransaction::GetMinFee
 24 2013-01-05 09:57:48 <stealth222> if (nBytes < 10kb && !(output < .01)) then relay
 25 2013-01-05 09:58:07 <stealth222> otherwise, require MIN_RELAY_TX_FEE
 26 2013-01-05 10:38:54 <gmaxwell> Pucilowski: fees have multiple purposes
 27 2013-01-05 10:39:34 <gmaxwell> Pucilowski: some transactions which objectively look like DOS attacks based on the crtieria in the software (resending small values fast, or involving lots of data) require fees or they won't get relayed.
 28 2013-01-05 10:39:45 <Jouke> not including fees is stupid, he'll figure it out and he wants to do it the hard way.
 29 2013-01-05 10:39:59 <gmaxwell> Without this behavior a griefer could flood the relay network with traffic and bitcoin would grind to a halt, even if miners were ignoring them.
 30 2013-01-05 10:40:03 <Pucilowski> im not actually looking to send transactions without fees in practice
 31 2013-01-05 10:40:24 <gmaxwell> Pucilowski: most normal transactions are sent without fees.
 32 2013-01-05 10:40:28 <Pucilowski> well, i do, but with small amounts to see how they propagate etc
 33 2013-01-05 10:40:45 <Jouke> small amounts is exactly when you need fees
 34 2013-01-05 10:41:36 <gmaxwell> So in any case, your client is aware of the anti-DOS rule, and so it refuses to create txn that it _knows_ won't go anywhere. (as it applies the same test it would apply for relaying).
 35 2013-01-05 10:42:55 <gmaxwell> If you remove that check what will happen is that you'll create transactions which don't forward and don't get mined.  And they'll be stuck, and will capture your inputs and make you lose funds (potentially all your funds) until you go hex edit your wallet to remove the dead transactions.
 36 2013-01-05 10:44:29 <Pucilowski> How does editing the wallet file help? If the unconfirmed undesirable 0tx fees are already out there in the network?
 37 2013-01-05 10:44:56 <Jouke> they are not in the network
 38 2013-01-05 10:45:20 <Jouke> Or maybe only a small part of the network
 39 2013-01-05 10:45:46 <gmaxwell> e.g. if you send 1e-8 btc (smallest possible amount) with a hacked up client so it doesn't impose a fee.. then it decides to use a 100 BTC input to form that transaction... none of your peers will _relay_ it (sub-dust output without fee) so the transaction will be totally stuck forever AND your 100 BTC will now be unspendable because its on hold waiting for the hopeless transaction.
 40 2013-01-05 10:46:33 <sipa> Pucilowski: if a transaction is considered spam, it is not relayed, so except for your direct neighbours, nobody knows about it
 41 2013-01-05 10:46:47 <gmaxwell> You can fix the latter problem by hex editing the wallet to make it forget that transaction so at least you can spend your funds.
 42 2013-01-05 10:47:07 <gmaxwell> To prevent this outcome sane software won't create doomed transactions. :)
 43 2013-01-05 10:55:16 <stealth222> I still say the relay agent and the wallet should be separate applications :)
 44 2013-01-05 10:56:10 <sipa> in the first place they should be separate processes
 45 2013-01-05 10:56:25 <sipa> that can still mean the same binary, or at least the same codebase
 46 2013-01-05 10:56:30 <stealth222> sure
 47 2013-01-05 10:57:43 <stealth222> if you want to use bitcoind as a relay agent only, you can always sign the transaction using a separate program and then use sendrawtransaction
 48 2013-01-05 10:58:40 <stealth222> but perhaps they could be even more tightly integrated - or perhaps it would be best for them to communicate via bitcoin protocol
 49 2013-01-05 10:58:44 <Pucilowski> does sendrawtransaction verify the tx meets all the rules?
 50 2013-01-05 10:58:51 <Pucilowski> or does it just broadcast the bits without caring
 51 2013-01-05 10:59:00 <stealth222> the transaction has to follow the rules
 52 2013-01-05 10:59:06 <gmaxwell> It gets tested.
 53 2013-01-05 10:59:29 <Pucilowski> there's no reason why you could not try broadcast a tx whether its valid or not
 54 2013-01-05 10:59:53 <stealth222> if you broadcast an invalid transaction (meaning it doesn't follow the protocol rules nor the bitcoind relay rules) it will be rejected
 55 2013-01-05 11:00:03 <stealth222> I mean, if you try to broadcast via bitcoind
 56 2013-01-05 11:00:05 <gmaxwell> Sure there is: in order to give you a reliable rejection from the API.
 57 2013-01-05 11:00:56 <gmaxwell> It's useful for the caller to know it failed??? this has saved me a bunch of time using sendrawtransaction.
 58 2013-01-05 11:01:07 <gmaxwell> Pucilowski: what are you trying to accomplish, in any case?
 59 2013-01-05 11:01:18 <Pucilowski> Just curious about things
 60 2013-01-05 11:02:51 <petertodd> if you're purely just curious try out what you want to do on testnet - you'll be able to mine the transaction yourself too
 61 2013-01-05 11:03:07 <gmaxwell> oh hey, neat someone sent 1btc to me out of the blue.
 62 2013-01-05 11:03:42 <Pucilowski> whats the difficulty on testnet anyway?
 63 2013-01-05 11:03:54 <gmaxwell> Yea, testnet is great for testing. Although the relay rules are somewhat relaxed there??? non-standard txn get relayed there.
 64 2013-01-05 11:04:03 <Pucilowski> must be so surreal to be able to actually mine blocks even if they're worthless
 65 2013-01-05 11:04:06 <gmaxwell> Pucilowski: whatever it is, it's 1 20 minutes after the last block.
 66 2013-01-05 11:04:07 <petertodd> trivial, it resets to 1 after 20 minutes
 67 2013-01-05 11:04:24 <stealth222> I mined 200 btc in a few hours using the built-in miner on testnet
 68 2013-01-05 11:04:26 <petertodd> otherwise I've seen it at about 150ish?
 69 2013-01-05 11:04:35 <Pucilowski> So it doesn't follow the regular rules?
 70 2013-01-05 11:04:42 <petertodd> Nope
 71 2013-01-05 11:04:59 <petertodd> It has a special case in main.cpp
 72 2013-01-05 11:05:01 <gmaxwell> "difficulty" : 31.50117728,
 73 2013-01-05 11:05:30 <gmaxwell> Pucilowski: it's slightly modified because in the past we had issues with people gpu mining it to a difficulty of a few hundred then leaving it stranded for weeks.
 74 2013-01-05 11:09:21 <stealth222> Pucilowski, having to follow the rules to get relayed is essential to the proper functioning of the network
 75 2013-01-05 11:10:13 <stealth222> if every node began to relay whatever came its way, there'd be so much garbage flooding the network that no resources would be left to process real transactions
 76 2013-01-05 11:10:49 <gmaxwell> Otherwise a couple instances of while true ; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.0000001 ; done  would take out the network.
 77 2013-01-05 11:11:36 <petertodd> Conversely, the existence of Bitcoin gives all sorts of interesting ways to make flood attacks expensive for *other* P2P networks.
 78 2013-01-05 11:13:33 <stealth222> bitcoin's policy is basically that you are entitled to flood the network with data as long as either you have the computing power to mine it into blocks or you are willing to pay sufficient fees
 79 2013-01-05 11:13:39 <gmaxwell> Yep. We may eventually be 'forced' to put in a general (non-currency) flooding p2p network into our p2p network just to disincentivize people for abusing transactions for that purpose. We can't count on other things to solve it for us because we actually can solve flooding better than anything else, it seems.
 80 2013-01-05 11:16:07 <gmaxwell> (obviously something else could still use bitcoin for antiflood, but at the moment it seems that the knoweldge of this isn't propagating well outside of bitcoin)
 81 2013-01-05 11:17:19 <stealth222> it would be possible to create a network where all output amounts are zero (miners get everything sent) and the outputs can be used instead for arbitrary data
 82 2013-01-05 11:17:41 <stealth222> the fee policy would depend on the message size
 83 2013-01-05 11:18:20 <gmaxwell> stealth222: careful, you're about to invent namecoin.
 84 2013-01-05 11:18:24 <stealth222> hehe
 85 2013-01-05 11:18:45 <gmaxwell> The point I was talking about, however, would have transactions that didn't get mined carrying data. So you could have non-immortal data.
 86 2013-01-05 11:18:47 <petertodd> Speaking of, what's the best "theory" on making sidechains work? Specifically I was thinking about a generalized "blockchain to ensure global visibility" thing, (yes, namecoin) and didn't find much (sane) writing about such stuff.
 87 2013-01-05 11:19:11 <gmaxwell> "use namecoin"
 88 2013-01-05 11:19:36 <petertodd> My understanding is namecoin isn't prunable in any way though.
 89 2013-01-05 11:20:19 <gmaxwell> it's just the same as bitcoin.
 90 2013-01-05 11:20:52 <gmaxwell> this is worse for namecoin because it means that you can't have a SPV resolver for dns, but you're not asking about DNS.
 91 2013-01-05 11:21:46 <petertodd> can't essentially because you care about the set of all "unspent txouts" -> domain names?
 92 2013-01-05 11:21:57 <gmaxwell> https://bitcointalk.org/index.php?topic=21995.0 < (I explain that issue there, and also suggested how it can be solved (that general idea has subsiquently been expanded on by others, but not implemented))
 93 2013-01-05 11:22:08 <gmaxwell> petertodd: right.
 94 2013-01-05 11:22:41 <petertodd> ah, thanks
 95 2013-01-05 11:24:08 <petertodd> whereas for a "sidechain to prove bank foo cheated" it doesn't matter so much, because we can just look at all the "txout" equivalent after the creation of the bank foo identity
 96 2013-01-05 11:25:04 <stealth222> you mean altchain?
 97 2013-01-05 11:25:41 <gmaxwell> stealth222: he means sidechain, e.g. something merged mined which may or may not be totally independant of bitcoin.
 98 2013-01-05 11:25:52 <stealth222> sidechain usually refers to chains that connect to the same genesis block but are shorter
 99 2013-01-05 11:25:57 <stealth222> no?
100 2013-01-05 11:26:07 <petertodd> correct me if I'm wrong, but altchain normally implies mining, whereas I don't want to limit the concept to pow mining
101 2013-01-05 11:26:23 <petertodd> for some apps "mining" via BTC fees would be reasonable
102 2013-01-05 11:26:33 <petertodd> timestamping for instance
103 2013-01-05 11:27:10 <Pucilowski> What happens when a transaction is broadcast and the node that would receive it normally is offline at the time - will he not be able to see until it has a confirmation?
104 2013-01-05 11:27:33 <stealth222> depends on how long it survives the mempool of other nodes
105 2013-01-05 11:27:36 <gmaxwell> Pucilowski: correct.
106 2013-01-05 11:27:43 <gmaxwell> stealth222: you don't see things in your peers mempols.
107 2013-01-05 11:27:48 <gmaxwell> er pools
108 2013-01-05 11:27:49 <stealth222> you can if you want to
109 2013-01-05 11:28:41 <stealth222> https://en.bitcoin.it/wiki/BIP_0035
110 2013-01-05 11:30:19 <gmaxwell> stealth222: yes, but the software doesn't because it would make data in mempools immortal.
111 2013-01-05 11:30:39 <gmaxwell> We'll have to add some mempool aging before we can actually use that at node startup.
112 2013-01-05 11:30:42 <stealth222> by default it doesn't - but that's not to stop you from implemementing a node that checks peer mempools
113 2013-01-05 11:31:47 <gmaxwell> Not breaking the network stops us from, right now. But sure, you can... though what you can program that has not been programmed yet doesn't answer Pucilowski's question. :P
114 2013-01-05 11:32:33 <petertodd> if you want your transaction to stick around in the mempool add a nLockTime'd output leading to another transaction with a hefty mining fee and tell people - guarantee you someone will hold onto it
115 2013-01-05 11:33:09 <petertodd> of course, "the mempool" it's in might not be a convenient one for you
116 2013-01-05 11:33:17 <gmaxwell> I'd take a bet no one would bother, apathy in bitcoin is amazing. :P
117 2013-01-05 11:33:21 <Pucilowski> so when do nodes stop propagating a transaction?
118 2013-01-05 11:33:25 <TD> i'd like to combine the mempool message with bloom filtering so SPV clients can download relevant unconfirmed transactions at startup
119 2013-01-05 11:33:49 <gmaxwell> TD: thats what thats there for.. does the current bloop patch not filter the BIP_0035 call?
120 2013-01-05 11:33:58 <petertodd> heh, someone broadcast my tx-within-a-tx within 5 minutes of me posting it...
121 2013-01-05 11:34:00 <gmaxwell> s/bloop/bloom/
122 2013-01-05 11:34:19 <TD> no
123 2013-01-05 11:34:23 <TD> it should do, i guess
124 2013-01-05 11:34:31 <TD> we need to fix the current bugs before adding new features to it though :)
125 2013-01-05 11:34:35 <gmaxwell> doh. I think so.
126 2013-01-05 11:35:54 <stealth222> so BIP_0035 would still send the entire mempool by default, yes?
127 2013-01-05 11:36:04 <stealth222> only if a client explicitly provided a bloom filter would it filter
128 2013-01-05 11:37:07 <stealth222> and a bloop patch might be even more interesting, gmaxwell :p
129 2013-01-05 11:38:36 <gmaxwell> (I use 'bloop' as another word in the foo/bar/baz sequence, and usually put it in debug messages and comments on code I intend to remove before committing for easy grepping... so I type it a lot)
130 2013-01-05 11:41:49 <gmaxwell> petertodd: that nested txn doesn't do what you want, alas. You could doublespend the inner txn before the locktime hits.
131 2013-01-05 11:41:52 <TD> stealth222: that's the idea. right now mempool always returns everything
132 2013-01-05 11:42:08 <TD> stealth222: which makes it not really usable from mobile phones because you'd end up downloading thousands of transactions at startup
133 2013-01-05 11:42:22 <gmaxwell> As a miner I would want to not allow anyone to mine the outer txn, until the inner txn locktime hit so I could get a chance at mining both.
134 2013-01-05 11:42:43 <TD> stealth222: the patch is a bit subtle because you need to do a topological sort of the mempool first, so the bloom filter is updated as you iterate through the transactions
135 2013-01-05 11:43:17 <petertodd> gmaxwell: of course, it's only worthwhile *after* the locktime hits and it's in the chain for good
136 2013-01-05 11:43:45 <gmaxwell> petertodd: but then why not skip the outer, and just author the inner to begin with?
137 2013-01-05 11:44:00 <petertodd> gmaxwell: because after the fact there is no proof that you didn't mine the inner yourself
138 2013-01-05 11:44:02 <stealth222> the bloom filter is on public keys/hashes of public keys, right?
139 2013-01-05 11:44:42 <stealth222> so the recipient would be the one to compute the bloom filter bits, yes?
140 2013-01-05 11:45:50 <petertodd> gmaxwell: the outer is just way of proving that everyone had a fair chance at mining the inner - a usable sidechain would be suitable too provided it's convincingly public
141 2013-01-05 11:45:53 <stealth222> are you saying that the other nodes would also be uploading peer bloom filters dynamically?
142 2013-01-05 11:45:57 <stealth222> err
143 2013-01-05 11:46:03 <stealth222> s/uploading/updating/
144 2013-01-05 11:46:49 <gmaxwell> petertodd: well, only if you count on people being able to reconize the inner txn. But I see your point. Still as mentioned, there is a disincentive to actually mine those outer txn until the last possible moment so there may be problems in getting them made public.
145 2013-01-05 11:46:54 <gmaxwell> stealth222: they do.
146 2013-01-05 11:47:31 <gmaxwell> stealth222: multiple data types are tested against it (e.g. output addresses and txids), when you get a hit you add the other data types from the hit.
147 2013-01-05 11:47:50 <stealth222> ok
148 2013-01-05 11:48:11 <gmaxwell> ah, now that I repeated that, it probably breaks the bloomfilter for loadbalancing idea, bummer.
149 2013-01-05 11:48:51 <petertodd> gmaxwell: yeah, it's unfortunate I can't make the inner use the outer as it's txin... that said, given a long enough nLockTime someone's going to mine it if it's stuffed into a isStandard tx
150 2013-01-05 11:48:54 <stealth222> what's the bloomfilter for loadbalancing idea?
151 2013-01-05 11:49:28 <stealth222> bloomfilters on peer hostnames?
152 2013-01-05 11:49:48 <gmaxwell> petertodd: your goals are at odds, if people automatically reconize the inner, that will be motivation to also block the outer. :P
153 2013-01-05 11:50:43 <gmaxwell> stealth222: 0_o, no. this was saying that if you wanted to reduce bandwidth usage on a relaying node you could compute a set of orthorgonal bloomfilters to send to your peers, so you'd get fewer duplicate advertisements. (and you'd still getblock like normal instead of pulling filtered blocks)
154 2013-01-05 11:50:52 <petertodd> gmaxwell: pretty much, I expect fees for the outer will just have to rise accordingly
155 2013-01-05 11:51:44 <stealth222> you could still do that, gmaxwell, by dividing up the keyspace accordingly
156 2013-01-05 11:51:55 <petertodd> afterall, it's never a sure deal that you'll be able to mine it, who knows how many miners have had the tx relayed to them
157 2013-01-05 11:52:17 <stealth222> assuming keys are uniformly distributed, of course
158 2013-01-05 11:53:28 <gmaxwell> stealth222: the point I was making is that the automatic updates will make it so that any filter with most of the bits set eventually gets all its bits set.
159 2013-01-05 11:54:57 <stealth222> there'd have to be a way of "expiring" old addresses
160 2013-01-05 11:55:02 <stealth222> old keys
161 2013-01-05 11:55:40 <stealth222> a simple bloom filter cannot do that - but more sophisticated ones can
162 2013-01-05 11:55:54 <gmaxwell> ... or just not updating it.
163 2013-01-05 11:56:08 <gmaxwell> so that your orthorgonal filters stay orthorgonal.
164 2013-01-05 11:56:22 <stealth222> but if it's not updated then it's up to the recipient to resend new filters
165 2013-01-05 11:56:37 <gmaxwell> yes, for the loadbalancing case you'd never have to send a new filter.
166 2013-01-05 11:56:47 <gmaxwell> the updating is good.
167 2013-01-05 11:57:07 <gmaxwell> Just not for abusing the bloomfilters for loadbalancing. Thats all I'm saying.
168 2013-01-05 12:05:21 <petertodd> gmaxwell: actually, that's all wrong, by broadcasting the inner tx to the mempool you make the decision to mine the outer completely independent of any attempt to block the inner
169 2013-01-05 12:07:04 <gmaxwell> petertodd: if the outer gets blocked you don't necessarily make the inner highly public, increasing your chances of being the party that mines it in the future.
170 2013-01-05 12:08:19 <petertodd> gmaxwell: no, but the *sender* of the outer can make the inner public themselves
171 2013-01-05 12:08:42 <petertodd> it's the nuclear option
172 2013-01-05 12:09:20 <gmaxwell> wtf. sd has created a test version of their spammy service ... and put it on the production network too.
173 2013-01-05 12:10:05 <gmaxwell> petertodd: they can try, but if miners refuse to mine the outer because they want to make it less public, they may not be very successful.
174 2013-01-05 12:10:42 <ThomasV> gmaxwell: hi, is bip 32 final?
175 2013-01-05 12:11:22 <petertodd> gmaxwell: but there's nothing special about the inner, except having nLockTime set, you're suggesting cartels basically, and I just don't see that
176 2013-01-05 12:11:54 <gmaxwell> ThomasV: No.
177 2013-01-05 12:12:08 <ThomasV> any eta?
178 2013-01-05 12:12:28 <petertodd> gmaxwell: and really, you don't actually need to use nLockTime if the value per tx pair is kept well under the block reward value
179 2013-01-05 12:12:40 <gmaxwell> petertodd: no. I'm suggesting miners behave rationally and the knowedlge of extracting the inner from outer is universal, both of which your idea requires.
180 2013-01-05 12:13:33 <gmaxwell> ThomasV: Ask sipa.
181 2013-01-05 12:13:49 <petertodd> gmaxwell: right, so with the inner tx being known already, and out there waiting to be mined, why would a miner want to wait to mine the outer tx? the outer tx is just information proving that the inner tx was publicly known before some block number remember
182 2013-01-05 12:13:51 <gmaxwell> ThomasV: this isn't just waiting on us. We must have some relevant cryptographers look it over too.
183 2013-01-05 12:14:45 <ThomasV> oh wow
184 2013-01-05 12:14:51 <gmaxwell> petertodd: because he doesn't want the inner to be known. It might be known now, but what about 2000 blocks from now?
185 2013-01-05 12:15:11 <ThomasV> gmaxwell: I always thought you were a relevant cryptographer
186 2013-01-05 12:15:55 <gmaxwell> ThomasV: Well, more relevant than just me. (And bytecoin)
187 2013-01-05 12:16:30 <petertodd> gmaxwell: if this mechanism becomes a common thing, say for anon-echaum-token-issuing banks, I expect miners will setup their mempools to save high-value tx's for as long as it takes, and equally I expect peer DoS prevention code to pop up on a "tit-for-tat" basis, IE, if you never broadcast high-value tx's to me, I'll never broadcast them to you
188 2013-01-05 12:17:03 <petertodd> (of course, it'll be interesting when sometimes it makes more sense to not build on the top block...)
189 2013-01-05 12:17:05 <gmaxwell> Bip-32 adds more usecases beyond just the type-2 derivation, e.g. making your chaincode quasipublic.  There may be more subtle implications.
190 2013-01-05 12:18:41 <gmaxwell> Really unlikely of course, but its prudent to have more eyes on it.
191 2013-01-05 12:20:53 <ThomasV> what do you mean? if you publish the master public key of a node, my understanding is that all child node sequences will be public, but other branches remain private
192 2013-01-05 16:35:52 <MC1984> if i have -debug set
193 2013-01-05 16:36:11 <MC1984> would the non truncated logfile writing interfere with the actual sync process
194 2013-01-05 16:37:39 <ThomasV> where should I make a pull request for the bitcoin.org website?
195 2013-01-05 16:42:27 <gmaxwell> ThomasV: https://github.com/bitcoin/bitcoin.org/pulls
196 2013-01-05 16:42:30 <gmaxwell> MC1984: No.
197 2013-01-05 16:42:39 <gmaxwell> MC1984: except by running you out of space entirely
198 2013-01-05 16:48:29 <ThomasV> gmaxwell: is there a way to send a pull request without forking a project? I find it a bit overkill :)
199 2013-01-05 16:48:35 <grau> gmaxwell: the blocktester (bluematt) seems quite bitcoinj specific to me, how is it used to test bitcoind ?
200 2013-01-05 16:57:37 <sipa> grau: it uses bitcoinj, but connects to another node (which needs some patch to allow a different chain with lower difficulty)
201 2013-01-05 16:57:45 <lianj> ThomasV: you could send a mail patch or point to your branch which you host on your server instead of github. but the github pull request think is nice because people can comment on it etc
202 2013-01-05 16:58:00 <sipa> grau: which it sends blocks, and verifies whether they get accepted or rejected, and reorganized correctly
203 2013-01-05 16:58:55 <grau> i see, is there a patch or script that supports that for bitcoind?
204 2013-01-05 16:59:01 <gmaxwell> yes, included with it.
205 2013-01-05 16:59:34 <grau> thanks
206 2013-01-05 16:59:53 <gmaxwell> (someday in the future that probably won't be required, because we'll mine a real chain for it, you'd just run with checkpoints disabled)
207 2013-01-05 17:00:58 <Evilmax> hi: i need help
208 2013-01-05 17:06:35 <ThomasV> lianj: ok, I created a fork
209 2013-01-05 17:07:07 <ThomasV> the electrum website moved to electrum.org, that's the reason of the pull
210 2013-01-05 17:15:32 <grau> gmaxwell: mining a chain just for testing was also my plan before. I think the nicest solution would be a jbehave file with blocks and tx listed and answers expected. Maybe I get it done.
211 2013-01-05 17:16:25 <gmaxwell> grau: well it's a little more complicated than that, to test reorginizsations you must go through sequences of blocks.
212 2013-01-05 17:16:37 <gmaxwell> and check to make sure its picked the right chain out of competing chains.
213 2013-01-05 17:16:42 <gmaxwell> it's not just pass/fail
214 2013-01-05 17:16:50 <grau> I know, thats what i mean
215 2013-01-05 17:16:56 <gmaxwell> (on a single block basis at least)
216 2013-01-05 17:17:59 <grau> the jbehave would say: assume this and this, and this happends then this is the expected outcome look up jbehave.org
217 2013-01-05 19:47:25 <cheako> Hello, I've a 6GB .bitcoin folder.  Any chance to reduce this?
218 2013-01-05 19:49:55 <sipa> cheako: right now, the best advice is using a lightweight client if it's really a problem
219 2013-01-05 19:50:11 <kuzetsa> cheako: that sounds normal for the regular (zero trust) client
220 2013-01-05 19:50:39 <Pucilowski> Does bitcoin-qt relay tx's by default?
221 2013-01-05 19:50:41 <kuzetsa> mine is 6GB too
222 2013-01-05 19:50:57 <kuzetsa> Pucilowski: yes
223 2013-01-05 19:51:25 <sipa> Pucilowski: yes, once
224 2013-01-05 19:54:22 <Pucilowski> How can I view the list of my peers?
225 2013-01-05 19:56:36 <sipa> getpeerinfo
226 2013-01-05 19:59:47 <gmaxwell> Pucilowski: watcha interested in peers for?
227 2013-01-05 20:00:07 <Pucilowski> playing around wtih double spends on my VMs
228 2013-01-05 20:01:38 <cheako> Did the size of the block chain double since Aug?  It looks like something happened in the may/jun time frame.
229 2013-01-05 20:02:18 <cheako> The block chain is over 4GB, what's the other 30% being used for?
230 2013-01-05 20:02:46 <gmaxwell> cheako: 1gb is probably debug.log, and a bit over 1gb is the indexes.
231 2013-01-05 20:03:03 <gmaxwell> The chain itself is about 4.3-4.4gb.  so there you have it.
232 2013-01-05 20:03:23 <gmaxwell> You can end up with junk extra chain data if you deleted your index at some point.
233 2013-01-05 20:03:54 <cheako> I'm using -printtoconsole for the vary reason.
234 2013-01-05 20:04:30 <gmaxwell> Well then you tell us.
235 2013-01-05 20:05:30 <cheako> 1.5G\t./blkindex.dat;  Can I stop the client and delete this?
236 2013-01-05 20:05:57 <cheako> Thanks for all the help.
237 2013-01-05 20:06:42 <gmaxwell> ... no, not unless you want a long wait and GB of additional wasted space.
238 2013-01-05 20:06:45 <gmaxwell> er 4GB
239 2013-01-05 21:03:02 <ThomasV> gmaxwell: thanks for the merge
240 2013-01-05 21:03:47 <gmaxwell> It took extensive review and consideration ... but it was the least I could do.
241 2013-01-05 21:04:06 <ThomasV> lol
242 2013-01-05 21:05:02 <gmaxwell> why is adblock 'correcting' bitcoin.org to bitcoin.og in my browser 0_o
243 2013-01-05 21:06:21 <ThomasV> adblock forced me to rename stats.ecdsa.org to statistics.ecdsa.org, because "stats" is frequently used for serving ads
244 2013-01-05 21:34:13 <gmaxwell> At wikimedia we changed the hash function used for uploaded image objects to output devowled base-32 instead of hex, because "/ad/" was getting blocked by people and generating a slow stream of complaints when 1/65k images didn't show for people.
245 2013-01-05 22:00:48 <sipa> gmaxwell: haha
246 2013-01-05 23:48:08 <da2ce7_d> sipa: yeah that would be great!
247 2013-01-05 23:50:23 <da2ce7_d> ok, I'm off bbl guys.