1 2013-08-29 00:09:23 <petertodd> jgarzik: signing updates is a good idea too - I've got a datastructure ideal for that called a merkle mountain range
  2 2013-08-29 00:11:45 <petertodd> https://bitcointalk.org/index.php?topic=240861.0 <- Finally! An alt-coin with a pretty UI! I've been waiting for that.
  3 2013-08-29 00:12:24 <petertodd> Reminds me: killer feature for our one-click alt-coin generator will be skinz.
  4 2013-08-29 00:12:44 <petertodd> Should also put a themesong of your choice into the genesis block.
  5 2013-08-29 00:12:57 <jgarzik> heh
  6 2013-08-29 00:13:51 <petertodd> Or maybe that should be the proof of work function? A memory hard one that requires calculating SHA256(SHA256(nonce + rickroll))
  7 2013-08-29 00:24:52 <petertodd> lol
  8 2013-08-29 00:25:06 <gmaxwell> just long enough for him to get redirected???
  9 2013-08-29 00:31:05 <helo> would it be unwise for there to be an option to "quarantine subsequent payments to addresses"?
 10 2013-08-29 00:31:20 <helo> so they won't be automatically used when doing a sendtoaddress/sendmany
 11 2013-08-29 00:32:16 <helo> to prevent cookie crumbing from reducing anonymity
 12 2013-08-29 00:32:25 <helo> *privacy
 13 2013-08-29 00:33:36 <gmaxwell> darnit!
 14 2013-08-29 00:33:58 <Cusipzzz> he lives
 15 2013-08-29 00:34:00 <gmaxwell> I guess his client doesn't stick to the new channel
 16 2013-08-29 00:34:19 <petertodd> zombie gavin
 17 2013-08-29 00:34:26 <gmaxwell> cooooiiinnnsss
 18 2013-08-29 00:34:36 <helo> heh
 19 2013-08-29 00:34:39 <warren> good thing zombie gavin doesn't have any important private keys
 20 2013-08-29 00:34:43 <warren> oh wait
 21 2013-08-29 00:34:45 <petertodd> wonder if we can trick him with alt-coins?
 22 2013-08-29 00:36:06 <Cusipzzz> ...
 23 2013-08-29 00:39:42 <helo> given the recent publicity highlighting privacy issues
 24 2013-08-29 01:15:48 <coingenuity> http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf interesting read
 25 2013-08-29 01:35:24 <jgarzik> OK, time to replace json_spirit.  with a 100-line json-for-C++ that actually works, and does not require many megabytes per compiled object + ram.
 26 2013-08-29 01:35:35 <jgarzik> (in my poolserver, not bitcoind)
 27 2013-08-29 02:17:01 <gmaxwell> coingenuity: interesting timing on that, enh?
 28 2013-08-29 02:17:37 <coingenuity> very :)
 29 2013-08-29 04:30:03 <Ferroh> gmaxwell, are you /u/nullc ?
 30 2013-08-29 04:31:56 <gmaxwell> Ferroh: yes.
 31 2013-08-29 04:35:36 <Ferroh> ok excellent.
 32 2013-08-29 04:58:09 <warren> gmaxwell: ping
 33 2013-08-29 04:58:45 <gmaxwell> hm?
 34 2013-08-29 04:59:25 <Diablo-D3> http://adterrasperaspera.com/blog/2013/08/29/how-to-make-the-inserthelp-key-emit-insert-in-iterm2
 35 2013-08-29 05:00:22 <Diablo-D3> gmaxwell: that markov chainer bot is in #bitcoin-assets now
 36 2013-08-29 05:01:04 <gmaxwell> good.
 37 2013-08-29 05:02:13 <Diablo-D3> gmaxwell: it doesnt seem to disturb anything
 38 2013-08-29 05:02:20 <Diablo-D3> its not even a markov chainer
 39 2013-08-29 05:02:22 <deego> Markov cahiner?
 40 2013-08-29 05:02:25 <Diablo-D3> it just repeats random lines people have said
 41 2013-08-29 05:02:36 <Diablo-D3> [02:45:36] <jorash> Quantum emulation is required to run quantum search algorithms such as Grover's (square root speedup) and GP (constant time).. versus classical linear time as SHA-2 is currently cracked. Class A shares indicate same rights as directors in the corp (including dividend from all revenue streams, not just miner which is a sideproject). 20-500x is the return based on the efficiency of the
 42 2013-08-29 05:02:36 <Diablo-D3> [02:45:37] <jorash> miner.
 43 2013-08-29 05:02:39 <Diablo-D3> for example
 44 2013-08-29 05:03:30 <deego> ah
 45 2013-08-29 05:04:28 <gmaxwell> oh quantum emulation guy was in there too?
 46 2013-08-29 05:16:00 <Diablo-D3> gmaxwell: they're not the same guy?
 47 2013-08-29 06:17:50 <arioBarzan> If one chooses "OP_HASH160 <pubKeyHash> OP_EQUAL" as scriptPubKey, assuming he has not revealed his pubKey, the coins sent to that scriptPubKey wouldn't be spendable without that pubKey, right?
 48 2013-08-29 06:20:30 <gmaxwell> arioBarzan: Perhaps you should ask what question you're really trying to answer?
 49 2013-08-29 06:20:47 <maaku> arioBarzan: but anyone could rewrite the transaction claiming that script
 50 2013-08-29 06:20:51 <gmaxwell> because I could say yes there, but it's meaningless. It's unspendable without the private key, and if you have the private key you have the public key.
 51 2013-08-29 06:21:09 <gmaxwell> oh you mean without a checksig! sorry I missed that!
 52 2013-08-29 06:21:23 <gmaxwell> arioBarzan: yea, that can be stolen by anyone when spent, esp miners.
 53 2013-08-29 06:22:07 <arioBarzan> gmaxwell: I know, but without pubKey I guess not possible to be stolen. Am I right?
 54 2013-08-29 06:23:06 <gmaxwell> sure. or better "the preimage" it doesn't have to be any special value there. its just data.
 55 2013-08-29 06:23:28 <gmaxwell> arioBarzan: but when you consume that output you must reveal the preimage to the network, and then it can be stolen.
 56 2013-08-29 06:26:39 <arioBarzan> it is similar to example at bitcoin.it about tx a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b which was hash of the Genesis block.
 57 2013-08-29 06:27:07 <arioBarzan> gmaxwell: Thanks
 58 2013-08-29 07:38:27 <an3k> would be nice if the transaction history in bitcoin-qt would show fixed length for bitcoins instead of rounding the prices
 59 2013-08-29 07:38:50 <an3k> Sending 6.2229 BTC shows up as 6.223 BTC
 60 2013-08-29 07:39:38 <sipa> you can set the number of decimals somewhere
 61 2013-08-29 07:39:45 <sipa> i think
 62 2013-08-29 07:42:03 <phantomcircuit> sipa, you can change it to mBTC but not the number of decimal places
 63 2013-08-29 07:42:09 <phantomcircuit> and that's jut confusing as fuck
 64 2013-08-29 07:42:39 <an3k> the mBTC stuff is also very confusing. Who ever used it?
 65 2013-08-29 07:43:30 <sipa> i certainly prefer 1.2 mBTC over 0.0012 BTC
 66 2013-08-29 07:44:06 <an3k> I don't because I never heard of it except for bitcoin-qt
 67 2013-08-29 07:44:27 <sipa> it's a standard SI prefix :)
 68 2013-08-29 07:44:42 <an3k> Si prefix are annoyng as hell and nobody uses them
 69 2013-08-29 07:44:49 <an3k> MibiByte and crap like that
 70 2013-08-29 07:44:59 <sipa> heh, that's not SI
 71 2013-08-29 07:45:37 <sipa> m just means milli
 72 2013-08-29 07:46:31 <an3k> it also could mean mega ... yes, there are developers using m for mega instead of M
 73 2013-08-29 07:46:45 <sipa> then they're wrong :)
 74 2013-08-29 07:47:19 <sipa> anyway, i think people will end up using mBTC and perhaps uBTC at some point in the future
 75 2013-08-29 07:47:43 <sipa> as too many zeroes is very hard to interpret fro humans
 76 2013-08-29 07:49:57 <an3k> that's right but bitcoins have to rise by factor 10 till ppl will use mBTC
 77 2013-08-29 07:50:27 <sipa> perhaps, yes
 78 2013-08-29 07:53:49 <an3k> Btw. is there an iPhone app in development?
 79 2013-08-29 07:55:24 <sipa> for/from?
 80 2013-08-29 07:56:29 <an3k> well, for bitcoins. just like bitcoin-qt but for iphone
 81 2013-08-29 07:56:32 <Scrat> an3k: no, because apple will kill it
 82 2013-08-29 07:56:46 <Scrat> we also dont like walled gardens here
 83 2013-08-29 07:56:47 <an3k> Scrat: you don't have to offer it through Apple Store ;)
 84 2013-08-29 07:57:20 <sipa> an3k: i'm sure there are several bitcoin-related iphone apps, but not a full client
 85 2013-08-29 07:57:22 <an3k> get the iphone configuration tool and with that you can install any app, even those not allowed on appstore :)
 86 2013-08-29 07:57:44 <sipa> a full node on mobile also doesn't really make sense, resource-wise
 87 2013-08-29 07:58:08 <an3k> sipa: no wallet for iPhone :( http://bitcoin.org/en/choose-your-wallet
 88 2013-08-29 07:58:08 <graingert> sipa, this is why a protocol to trust the desktops I operate is needed
 89 2013-08-29 07:58:20 <graingert> (relative I)
 90 2013-08-29 07:58:28 <graingert> not just trust graingert
 91 2013-08-29 07:58:31 <sipa> graingert: SPV + trusted peer
 92 2013-08-29 07:58:40 <graingert> s/peer/peers/
 93 2013-08-29 07:58:44 <sipa> yes
 94 2013-08-29 07:58:51 <graingert> yes that
 95 2013-08-29 07:58:53 <graingert> is there one?
 96 2013-08-29 07:58:59 <sipa> for android, sure
 97 2013-08-29 07:59:15 <graingert> tbh trusted peer group would be useful so only one of my desktops bother checking
 98 2013-08-29 07:59:16 <Scrat> the android wallet is the only mobile SPV client, correct?
 99 2013-08-29 07:59:18 <sipa> an SPV node would certainly work - there exists one for Android - but i don't know if anyone would bother doing the effort of writing one with such a high chance of being rejected (and thus not commercially useful)
100 2013-08-29 07:59:25 <Scrat> does it use bitcoinj code?
101 2013-08-29 07:59:28 <sipa> yes
102 2013-08-29 08:03:54 <phantomcircuit> sipa, also you'd have to implement the entire thing in objective c
103 2013-08-29 08:03:55 <phantomcircuit> which is
104 2013-08-29 08:03:57 <phantomcircuit> lol nothx
105 2013-08-29 08:31:23 <_dr> does anyone know a tool to dump the current utxo other than the blockparser? (blockparser is way too slow)
106 2013-08-29 09:57:33 <Luke-Jr> well this is a surprise. I accidentally xz'd some bz2 files. They're smaller than either bz2 or xz alone
107 2013-08-29 10:11:30 <phantomcircuit> Luke-Jr, MAGIC
108 2013-08-29 10:16:31 <warren> Luke-Jr: conman's magic compression tool that is slow as heck can often do better.
109 2013-08-29 10:16:47 <Luke-Jr> warren: as you say, it's slow as heck :/
110 2013-08-29 10:16:52 <Luke-Jr> warren: especially on 32-bit
111 2013-08-29 10:19:49 <sturles> I have a compression tool which _always_ make the file at least two characters shorter.  Unfortunately it makes the file name two or three characters longer as well, so it isn't very useful on large files...
112 2013-08-29 10:20:45 <phantomcircuit> sturles, lol
113 2013-08-29 10:20:48 <phantomcircuit> that one guy
114 2013-08-29 10:20:50 <phantomcircuit> i love that guy
115 2013-08-29 10:20:58 <wumpus> sturles: maybe you could use the extended attributes instead, it's less bothersome than the filename :)
116 2013-08-29 10:21:03 <phantomcircuit> poorly thought out compression challenges
117 2013-08-29 10:23:44 <sturles> wumpus: Extended attributes are often poorly handled when files are copied or moved.
118 2013-08-29 10:25:24 <wumpus> well yeah, that's too bad isn't it, just add to the disclaimer that the compressed file is fragile and should not be copied or moved
119 2013-08-29 10:30:00 <SomeoneWeird> lol
120 2013-08-29 10:36:17 <michagogo> 
ACTION wonders if jgarzik's here

121 2013-08-29 10:38:03 <ahmedbodi> me too michagogo
122 2013-08-29 12:21:29 <dustjn> What's the standard way of referring to the real bitcoin blockchain+network in contrast to testnet? I've seen libraries that call it "prod", other people say it should be "Bitcoin" with a capital B... how do the core devs refer to it?
123 2013-08-29 12:22:15 <sipa> i call it mainnet usually
124 2013-08-29 12:22:23 <aspect__> livenet/mainnet?
125 2013-08-29 12:23:36 <sipa> the current source code has CMainParams and CTestNetParams
126 2013-08-29 12:45:12 <UukGoblin> dustjn, where-you-shouldn't-pay-200btc-fee-net ;-)
127 2013-08-29 12:51:22 <Luke-Jr> dustjn: mainnet seems common for devs
128 2013-08-29 12:52:06 <dustjn> sipa, aspect__, Luke-Jr, thank you.
129 2013-08-29 12:52:23 <dustjn> UukGoblin: I have surplus laughs.
130 2013-08-29 12:58:25 <Luke-Jr> jgarzik: you're aware pullreq submitters *can't* reopen ones you close? "Closing. Feel free to reopen, if feedback is addressed."
131 2013-08-29 14:36:43 <Diapolo> Can someone try to reach 2l2u6mrojvm6zypx.onion?
132 2013-08-29 14:37:20 <Diapolo> And z2pq5jlss2cnxtm2.onion (testnet).
133 2013-08-29 15:04:41 <Diapolo> Pretty cool, freenode IRC via Tor connected to their hs
134 2013-08-29 15:48:26 <Austin_Powers> Rock n roll, baby
135 2013-08-29 15:48:44 <jgarzik> 
ACTION just wrote JSON lexer and parser, in flex/bison++

136 2013-08-29 15:48:53 <jgarzik> the generated code is pretty big...
137 2013-08-29 15:48:59 <jgarzik> ?and yet it is 10% of json_spirit
138 2013-08-29 15:49:50 <phantomcircuit> jgarzik, tryign to replace that monstrosity? :)
139 2013-08-29 15:50:31 <jgarzik> phantomcircuit, writing a c++ pool server, and couldn't take it anymore
140 2013-08-29 15:50:49 <jgarzik> tried using json_spirit, but now the writer crapped out on me, for stupid reasons
141 2013-08-29 15:51:05 <phantomcircuit> heh
142 2013-08-29 15:51:11 <jgarzik> I could fix it, but replacing the shite with something 10% of json_spirit's size was fun
143 2013-08-29 15:51:13 <phantomcircuit> jgarzik, im busy improving wallet performance
144 2013-08-29 15:51:18 <phantomcircuit> so much low hanging fruit...
145 2013-08-29 15:51:21 <jgarzik> haven't lexed and yacced in a while
146 2013-08-29 15:52:16 <phantomcircuit> "balance" : 606.25000000,
147 2013-08-29 15:52:16 <phantomcircuit> my wallet with nothing but regtest coinbase transactions
148 2013-08-29 15:52:17 <phantomcircuit> wat
149 2013-08-29 15:52:42 <phantomcircuit> oh i see the block reward halfs much faster in regtest
150 2013-08-29 15:52:48 <phantomcircuit> interesting
151 2013-08-29 15:53:00 <jgarzik> https://code.google.com/p/vjson/ would probably achieve another multiple of compactness, but that requires manual linked list traversal.  no useful APIs.
152 2013-08-29 15:59:37 <phantomcircuit> jgarzik, also https://github.com/bitcoin/bitcoin/issues/2736
153 2013-08-29 15:59:41 <phantomcircuit> this is seriously annoying
154 2013-08-29 16:00:00 <phantomcircuit> CheckTransaction fails when loading if the dependent transactions haven't been confirmed
155 2013-08-29 16:00:21 <phantomcircuit> since they're loaded after the tx with dependencies
156 2013-08-29 16:00:40 <phantomcircuit> i guess nobody noticed because the mempool is fine until you restart
157 2013-08-29 16:00:52 <phantomcircuit> and by then most peoples transactions have been broadcast
158 2013-08-29 16:02:37 <phantomcircuit> actually that doesn't make sense
159 2013-08-29 16:02:55 <phantomcircuit> IsFromMe dependent transactions would necessarily be loaded first
160 2013-08-29 16:33:55 <phantomcircuit> jgarzik, are you aware of the reason vtxPrev is used instead of walking the dependency tree and looking them up with pwallet->mapWallet?
161 2013-08-29 16:33:59 <phantomcircuit> i assume there is one
162 2013-08-29 16:34:22 <jgarzik> phantomcircuit, was mapWallet in 0.1.x?
163 2013-08-29 16:34:29 <phantomcircuit> i have no idea
164 2013-08-29 16:34:52 <jgarzik> 
ACTION isn't much of an expert on the wallet side of bitcoind

165 2013-08-29 16:35:09 <jgarzik> still learning a few details here and there, while making the JS signing tool
166 2013-08-29 16:35:42 <jgarzik> like: the format and order of signatures in scriptSig, in a partially signed TX
167 2013-08-29 16:35:52 <phantomcircuit> 223b6f1b src/main.cpp (Wladimir J. van der Laan 2011-05-15 09:11:04 +0200 1124)         BOOST_FOREACH(CMerkleTx& tx, vtxPrev)
168 2013-08-29 16:38:12 <sipa> phantomcircuit: dependencies are not necessarily in mapWallet
169 2013-08-29 16:39:03 <sipa> i think
170 2013-08-29 16:39:33 <phantomcircuit> sipa, i believe everything in vtxPrev should be in mapWallet
171 2013-08-29 16:39:40 <sipa> is, or should be?
172 2013-08-29 16:40:13 <phantomcircuit> sipa, im not sure about older wallets but current ones for sure
173 2013-08-29 16:40:19 <sipa> a second-level dependency is not necessarily a transaction that qualifies as IsMine or IsFromMe
174 2013-08-29 16:40:32 <phantomcircuit> unless there's someweirdness where vtxPrev is serialized into the "tx" record with the actual tx
175 2013-08-29 16:40:40 <sipa> yes, it is
176 2013-08-29 16:40:46 <phantomcircuit> hmm
177 2013-08-29 16:40:49 <sipa> that's the point
178 2013-08-29 16:40:51 <phantomcircuit> ok then i have to rethink this
179 2013-08-29 16:40:58 <sipa> so unconfirmed dependencies can get rebroadcast
180 2013-08-29 16:41:30 <phantomcircuit> sipa, as it stands the logic would do that for any "tx" record even if it wasn't IsFromMe
181 2013-08-29 16:41:38 <phantomcircuit> but i can see how that might be confusing
182 2013-08-29 16:41:48 <sipa> ?
183 2013-08-29 16:41:57 <sipa> you should rebroadcast any dependency
184 2013-08-29 16:42:03 <sipa> even if it doesn't apply to you
185 2013-08-29 16:42:28 <phantomcircuit> sipa, right i was asking if the vtxPrev is serialized into the same "tx" record as the IsMine transaction
186 2013-08-29 16:42:47 <sipa> it's just part of the CWalletTx
187 2013-08-29 16:43:00 <sipa> and remains there
188 2013-08-29 16:43:04 <phantomcircuit> hmm
189 2013-08-29 16:43:15 <phantomcircuit> ok so the logic needs to be more complicated than i initially thought
190 2013-08-29 16:43:17 <phantomcircuit> that's unfortunate
191 2013-08-29 16:43:34 <sipa> i suppose it makes sense to store the dependencies directly in the wallet
192 2013-08-29 16:43:47 <sipa> flagged as neither-from-or-to-me-yet-still-important
193 2013-08-29 16:43:52 <phantomcircuit> it probably makes sense for the dependencies to have their own record
194 2013-08-29 16:43:55 <michagogo> 
ACTION checks the forum thread to see if jgarzik put up the thing

195 2013-08-29 16:44:06 <phantomcircuit> but doing that would require extensive checking to make sure IsMine() is called everywhere it should be
196 2013-08-29 16:44:13 <phantomcircuit> and im not sure i want to do that
197 2013-08-29 16:44:28 <phantomcircuit> it should be easy enough to work around that limitation though
198 2013-08-29 16:44:50 <michagogo> 
ACTION complys with jgarzik's request to nag him

199 2013-08-29 16:45:00 <michagogo> 
ACTION complies* with jgarzik's request to nag him

200 2013-08-29 16:45:09 <phantomcircuit> basically walk vtxPrev and then talk anything in mapWallet that's also dependent and unconfirmed
201 2013-08-29 16:45:29 <phantomcircuit> which will only work is there's a ridiculous chain of your own tx's but that's ok
202 2013-08-29 16:46:10 <maaku> does signmessage base64-encode prior to signing?
203 2013-08-29 16:46:20 <sipa> prior? no
204 2013-08-29 16:46:28 <phantomcircuit> possibly vtxPrev should store dependent transactions which are not IsFromMe() and then rely on mapWallet for those that are IsFromMe()
205 2013-08-29 16:46:29 <sipa> the result is base64 encoded
206 2013-08-29 16:46:31 <gribble> The operation succeeded.
207 2013-08-29 16:46:31 <michagogo> ;;later tell jgarzik nag
208 2013-08-29 16:46:36 <phantomcircuit> which would probably end up being optimal behavior
209 2013-08-29 16:46:57 <phantomcircuit> but would require changes everywhere vtxPrev is used
210 2013-08-29 16:46:59 <maaku> there's no processing on the input, however?
211 2013-08-29 16:47:22 <CodeShark> are you guys talking about double-spend detection for the wallet?
212 2013-08-29 16:47:47 <phantomcircuit> CodeShark, no im talking about an extremely rare edge case that i would guess literally nobody has ever hit
213 2013-08-29 16:48:03 <phantomcircuit> which just makes the mempool reject IsFromMe() transactions since it cant find the inputs
214 2013-08-29 16:48:35 <phantomcircuit> indeed hitting this would probably be computationally infeasible due to a performance issue
215 2013-08-29 16:48:42 <phantomcircuit> which once i fixed made this obvious
216 2013-08-29 16:48:48 <phantomcircuit> but it's not a real problem so whatever
217 2013-08-29 16:49:47 <CodeShark> hmm, are you talking about spending unconfirmed coins?
218 2013-08-29 16:49:54 <phantomcircuit> yup
219 2013-08-29 16:50:26 <phantomcircuit> i improved the performance of IsConfirmed for that specific use case by a lot (actually i did it wrong but i can fix that)
220 2013-08-29 16:58:51 <phantomcircuit> sipa, https://github.com/bitcoin/bitcoin/pull/2952
221 2013-08-29 16:59:36 <phantomcircuit> switches the search to an explicit breadth first using tx hash as identifier
222 2013-08-29 16:59:49 <phantomcircuit> searches both mapWallet and vtxPrev
223 2013-08-29 17:00:03 <phantomcircuit> and is also much faster
224 2013-08-29 17:00:24 <phantomcircuit> there's still one optimization available but it's marginal
225 2013-08-29 17:00:31 <phantomcircuit> eh i'll add it why not...
226 2013-08-29 17:01:34 <gmaxwell> phantomcircuit: INCLUDE SOME BENCHMARK NUMBERS. :P  To someone who doesn't already know how laughably slow it is, it's not clear why taking your patch is important. (I know, but, e.g. gavin may not)
227 2013-08-29 17:01:51 <phantomcircuit> gmaxwell, i honestly have no idea what the complexity even is
228 2013-08-29 17:02:00 <phantomcircuit> fractal or something insane
229 2013-08-29 17:02:18 <phantomcircuit> er
230 2013-08-29 17:02:20 <phantomcircuit> words
231 2013-08-29 17:02:48 <gmaxwell> yea, I know. I gave up naming the complexity before, it's worse than quadratic.  But you know, test it on some big testnet wallet and give a figure. :P
232 2013-08-29 17:03:52 <phantomcircuit> gmaxwell, i think it's actually factorial time since it ends up walking the same branches many times
233 2013-08-29 17:04:05 <phantomcircuit> O(n!)
234 2013-08-29 17:04:43 <phantomcircuit> yeah that's about right
235 2013-08-29 17:04:53 <phantomcircuit> it fails completely with only like 10 unconfirmed inputs
236 2013-08-29 17:05:15 <sipa> so, give some real numbers
237 2013-08-29 17:05:20 <phantomcircuit> yeah i will
238 2013-08-29 17:05:40 <phantomcircuit> im switching from setAlreadyDone to setAlreadyQueued
239 2013-08-29 17:05:51 <phantomcircuit> which will further reduce runtime
240 2013-08-29 17:05:56 <phantomcircuit> to pretty much optimal
241 2013-08-29 17:06:00 <gmaxwell> Yea, I don't care about the asymptotic complexity much, just give a "8 unconfirmed tx is 30 seconds vs <1 second"
242 2013-08-29 17:06:21 <phantomcircuit> 30 seconds?
243 2013-08-29 17:06:26 <phantomcircuit> more liek 5 minutes
244 2013-08-29 17:06:33 <sipa> ehh... wut?
245 2013-08-29 17:06:34 <gmaxwell> for 8? I didn't think it was that bad.
246 2013-08-29 17:06:43 <gmaxwell> I thought it took like 20 to get it up to minutes.
247 2013-08-29 17:07:00 <phantomcircuit> gmaxwell, it depends on if they're chained together
248 2013-08-29 17:07:15 <phantomcircuit> if they are you end up walking the same tree of unconfirmed tx's many times
249 2013-08-29 17:07:32 <phantomcircuit> if you just have 8 unconfirmed that depend on only confirmed it's fast
250 2013-08-29 17:07:39 <phantomcircuit> which is why most people dont notice it's slow
251 2013-08-29 17:07:46 <gmaxwell> regardless, yea, I know there are cases where just a few (like 20) unconfirmed tx can get it up to several minutes.
252 2013-08-29 17:08:24 <phantomcircuit> gmaxwell, someone tried to double spend against a wallet i control
253 2013-08-29 17:08:48 <phantomcircuit> i had to remove a tiny tx since the runtime trying to resolve it's dependencies was getting into 30 minutes
254 2013-08-29 17:08:58 <sipa> wow
255 2013-08-29 17:08:59 <phantomcircuit> so relaytx was just running in a loop
256 2013-08-29 17:09:05 <sipa> i had no clue it was that bad
257 2013-08-29 17:09:09 <gmaxwell> at times I've regarded it as a feature, since stops some morons from DOS attacking the network with a shell script. So maybe we also need to add a sending rate limiter at the same time we fix this.
258 2013-08-29 17:09:17 <sipa> see: real numbers are useful :p
259 2013-08-29 17:11:08 <CodeShark> the RPC latency is already a rate limiter :p
260 2013-08-29 17:11:42 <phantomcircuit> gmaxwell, the main defense there is that most people wouldn't want to spend the tx fees to get stuff like that relayed
261 2013-08-29 17:11:53 <phantomcircuit> actually im not sure the relay rules even allow for chained unconfirmed txs
262 2013-08-29 17:12:10 <gmaxwell> phantomcircuit: yea thats the _real_ defense. Though a rate limiter might still be prudent.
263 2013-08-29 17:12:13 <gmaxwell> phantomcircuit: they do.
264 2013-08-29 17:12:53 <phantomcircuit> gmaxwell, it's not exactly fast even after this is fixed to do that sort of flooding
265 2013-08-29 17:12:54 <CodeShark> they most certainly do - I've used them numerous times
266 2013-08-29 17:13:02 <phantomcircuit> since the coinselection process is still really slow
267 2013-08-29 17:13:29 <phantomcircuit> im upto 360 tx's and it's now the bottleneck
268 2013-08-29 17:13:31 <phantomcircuit> which is reasonable
269 2013-08-29 17:13:47 <gmaxwell> Ultimately we can only stop such attacks with economics, since truly malicious parties will just remove limiters... but making economic antispam agressive has costs for non-attackers, esp since the network can't really tell "these 50 txn came from one person" and so the controls can only have linear costs.
270 2013-08-29 17:13:54 <owowo> any bitcointalk mod in here that could unban me?
271 2013-08-29 17:14:00 <phantomcircuit> so it's now fast enough that a real business with a burst of tx's wouldn't be screwed
272 2013-08-29 17:14:08 <phantomcircuit> but an attacker wouldn't find this particularly useful
273 2013-08-29 17:14:18 <gmaxwell> owowo: only global mods and theymos can unban people. What were you banned for?
274 2013-08-29 17:14:30 <phantomcircuit> since it's still much slower than just doing rawtransactions stuff
275 2013-08-29 17:15:14 <phantomcircuit> gmaxwell, well in this case the relay rules could impose increasing fees for transactions dependent on other unconfirmed transactions
276 2013-08-29 17:15:23 <owowo> for making the mod banning me,... it was intentionally and over on year ago when I trolled the trolls in a BFL thread
277 2013-08-29 17:15:32 <phantomcircuit> since that's what gets a performance boost here
278 2013-08-29 17:16:13 <owowo> gmaxwell:  http://i.imgur.com/xdgokaZ.png
279 2013-08-29 17:16:44 <phantomcircuit> i doubt you got banned for that
280 2013-08-29 17:16:53 <phantomcircuit> there's much worse on the forum than that
281 2013-08-29 17:17:01 <owowo> you can doubt but that's the truth
282 2013-08-29 17:17:30 <petertodd> phantomcircuit: The relay rules basically stop spamming the network based on the idea that a transaction will be mined, thus the fee/priority will be spent, so yes increasing fees to relay for long unconfirmed chains makes a hell of a lot of sense.
283 2013-08-29 17:18:36 <petertodd> phantomcircuit: The other issue is it needs to be possible to tell a peer "Here's some high fee tx, and it's worth it to include parents a, b, c to mine the tx"
284 2013-08-29 17:18:51 <gmaxwell> petertodd: I'd commented before that address reuse is one way someone can voluntarily signal that the txn all belong to the same party, and we should use that for anti-spam when they do.... likewise for unconfirmed chains, so I agree.
285 2013-08-29 17:18:56 <phantomcircuit> petertodd, children*
286 2013-08-29 17:19:19 <gmaxwell> Just because attackers can act in a way to make their attack transactions look mostly isolated, doesn't mean that we shouldn't do grouping QOS when they don't.
287 2013-08-29 17:19:20 <petertodd> gmaxwell: ha, interesting way to talk about address re-use
288 2013-08-29 17:19:21 <maaku> gmaxwell: i'm beginning to think that coinjoin should be a multi-party & blinding extensions to the payment protocol
289 2013-08-29 17:19:51 <petertodd> maaku: Why? coinjoin is payment protocol compatible without anything else
290 2013-08-29 17:19:57 <gmaxwell> maaku: payment protcol will have enough of an uphill battle without layering on more things.
291 2013-08-29 17:19:58 <phantomcircuit> does anybody know the dev for multibit?
292 2013-08-29 17:20:16 <phantomcircuit> i've been trying to get it to build for a while now with the idea of incorporating automated coinjoin
293 2013-08-29 17:20:32 <maaku> i mean a separate, later extension; there's no reason to hold up development of the payment protocol
294 2013-08-29 17:20:51 <maaku> but as i implement blinded coinjoin, i'm making request & response objects that look very similar to payment protocol
295 2013-08-29 17:20:55 <petertodd> maaku: Anyway I'm skeptical that any of this blinding stuff is needed on day 1 - just make broadcasting the coinjoin-related messages expensive in terms of some limited resource and you're fine. Remember that all blinding does is optimize anit-dos efforts.
296 2013-08-29 17:21:07 <maaku> well i've got the blinding stuff done
297 2013-08-29 17:21:09 <petertodd> maaku: Even with blinding you still need that underlying limited resource.
298 2013-08-29 17:21:23 <maaku> it's just all the other protocol and DoS issues that are trouble
299 2013-08-29 17:21:49 <gmaxwell> petertodd: blinding doesn't just optimize anti-dos, in at least some protocol cases its required in order to keep the players from knowing the mapping.
300 2013-08-29 17:21:50 <petertodd> maaku: Exactly. Talking about blidning first is just plain getting ahead of yourself.
301 2013-08-29 17:21:59 <maaku> petertodd: how is blinding related to DoS?
302 2013-08-29 17:22:13 <phantomcircuit> petertodd, blinding allows for not using tor to submit input/output pairs independently
303 2013-08-29 17:22:27 <phantomcircuit> which is important since tor is annoying and not as provably anonymous as blinding
304 2013-08-29 17:22:30 <petertodd> gmaxwell: Yes, in some protocols, but with anti-dos it's just as easy to separate the steps of asking for an output and advertising willingness to add an input.
305 2013-08-29 17:22:38 <phantomcircuit> indeed im now extremely suspicious of tor
306 2013-08-29 17:23:08 <phantomcircuit> given the information sharing between many foreign governments the idea that they're all sharing tor connection timing information and can act as a global observer seems fairly likely
307 2013-08-29 17:23:43 <phantomcircuit> (or at least something approaching a global observer)
308 2013-08-29 17:23:59 <petertodd> phantomcircuit: The one case where fancy blinding helps is when you do collectively come up with the full set of txins, and then you reveal that full set in one go. But that makes the whole process take longer anyway, and IMO we're much better off getting solid 2-party coinjoin working first.
309 2013-08-29 17:24:22 <phantomcircuit> shrug
310 2013-08-29 17:24:37 <phantomcircuit> the hardest part is clientside making sure the tx includes the input/output
311 2013-08-29 17:24:42 <phantomcircuit> which is relatively easy
312 2013-08-29 17:24:48 <petertodd> phantomcircuit: trivial...
313 2013-08-29 17:24:58 <phantomcircuit> well it should be
314 2013-08-29 17:25:01 <phantomcircuit> but people gonna stupid
315 2013-08-29 17:25:11 <gmaxwell> maaku: what petertodd means is that if you just have people connected and provide outputs with no protection other than perhaps a pow that any attack is purely a DOS (since no one will sign if their output is left out)
316 2013-08-29 17:25:27 <gmaxwell> maaku: but since you've already implemented the blinding, sweet.
317 2013-08-29 17:25:48 <petertodd> maaku: What specific type of blinding have you implemented?
318 2013-08-29 17:25:56 <gmaxwell> To correct phantomcircuit's tor fears you would also need a homorphic encryption mixer. ... yet more work.