1 2014-09-07 01:52:50 <gmaxwell> dhill: yes, I cited those particular reasons earlier too; actually there are even more than he's list. E.g. the kernel will save context in memory that can sit around with no promise of ever getting zeroed. All that can be done is a best effort attempt; the talk of language extensions for it just seems unlikely to me, eliminating all the leak paths would mean enormous performance hits, and would likely give a false sense of security when ...
  2 2014-09-07 01:52:56 <gmaxwell> ... additional leak paths still existed (e.g. the kernel as mentioned above)
  3 2014-09-07 02:56:37 <earlz> So is a coinbase transaction allowed to be non-standard?
  4 2014-09-07 02:56:58 <earlz> I heard that it isn't, but can't pinpoint the exact code that prevents it
  5 2014-09-07 02:57:43 <mr_burdell> like could it pay out only 0.00000001?
  6 2014-09-07 02:57:56 <earlz> no
  7 2014-09-07 02:58:05 <mr_burdell> would that block not get relayed?
  8 2014-09-07 02:58:18 <earlz> Like it could pay to something other than a public key/public key hash
  9 2014-09-07 02:58:39 <earlz> liek could a coinbase transaction be a "puzzle" transaction or some such
 10 2014-09-07 02:59:08 <mr_burdell> you'd be paying to a hash, right?
 11 2014-09-07 02:59:36 <earlz> eya
 12 2014-09-07 02:59:37 <earlz> yea
 13 2014-09-07 02:59:53 <earlz> but I mean, somehting that would count as non-standard, so wouldn't normally be relayed
 14 2014-09-07 03:02:44 <Luke-Jr> earlz: the Bitcoin protocol doesn't have any concept of "non-standard"
 15 2014-09-07 03:03:03 <Luke-Jr> that's strictly relay and miner policy
 16 2014-09-07 03:03:12 <Luke-Jr> … and of course what has been specified in standards
 17 2014-09-07 03:23:02 <petertodd> earlz: transactions already in blocks always bypass the standardness checks
 18 2014-09-07 03:34:18 <earlz> ah, I thought there was some kind of enforcement of what could eb a coinbase transaction, specifically
 19 2014-09-07 03:34:42 <earlz> I guess in theory you could mine to scripthash and what not
 20 2014-09-07 03:34:44 <Luke-Jr> earlz: only the input
 21 2014-09-07 03:35:20 <Luke-Jr> 1 input, to a null:-1 outpoint, no more than 100 bytes scriptSig which is never executed and must begin with a push of the height
 22 2014-09-07 03:35:38 <Luke-Jr> outputs can be any valid output
 23 2014-09-07 03:35:57 <earlz> ok, thanks for clearing that up
 24 2014-09-07 03:53:56 <gmaxwell> I'm guessing that no one expected or intends that whitebind should disable the ordinary default bind behavior?
 25 2014-09-07 04:01:58 <jgarzik> sigh. this is why I went with a simple whitelist....
 26 2014-09-07 04:07:46 <gmaxwell> jgarzik: :) This is what testing is for. :)
 27 2014-09-07 04:08:30 <gmaxwell> I wouldn't have been able to use the whitelist on the host I just noticed this on... it has matt's relay daemon on localhost, and tor hs peers (which also connect from 127.0.0.1), I very much don't want to whitelist the hs peers.
 28 2014-09-07 04:09:31 <jgarzik> true
 29 2014-09-07 04:18:14 <Arnavion> I just saw the discussion about (trying to) build bitcoin with MSVC here:   https://github.com/bitcoin/bitcoin/pull/4824
 30 2014-09-07 04:18:38 <Arnavion> FWIW building with MSVC toolchain doesn't necessarily need checking in and maintaining VS project / solution files
 31 2014-09-07 04:19:01 <Arnavion> For building GTK on Windows for the HexChat client, we use Mozilla's mozilla-build environment
 32 2014-09-07 04:19:10 <Arnavion> which is basically msys that uses cl.exe as the compiler
 33 2014-09-07 04:19:44 <Arnavion> (Of course it does have problems such as most compiler switches not being the same etc.)
 34 2014-09-07 04:20:20 <Luke-Jr> Arnavion: I don't think anyone objects to checking it in, as long as it's maintained. You might hit a problem is MSVC doesn't like standard C++ though..
 35 2014-09-07 04:20:36 <Luke-Jr> if*
 36 2014-09-07 04:20:51 <Luke-Jr> Arnavion: note that's rapidly becoming C++11
 37 2014-09-07 04:20:56 <Arnavion> I'm saying there might be nothing to checking in and maintain, assuming m-b's configure is modern enough to deal with bitcoin's script
 38 2014-09-07 04:21:29 <Arnavion> If it does come down to checking in and maintaining project files, I wouldn't want to do it either
 39 2014-09-07 04:32:27 <gmaxwell> heads up, some scammer has registered bitcoin.org username on skype and is spamming it around, no idea what they're upto... doubt its good. :)
 40 2014-09-07 09:35:35 <dabura667> Question: is changing an input's sequence to be something OTHER than 0xffffffff considered non-standard? or will any sequence value be accepted by miners?
 41 2014-09-07 13:42:00 <michagogo> Anyone happen to know if petertodd's dust-be-gone is still active?
 42 2014-09-07 13:42:49 <dabura667> Last time I tried it, no.
 43 2014-09-07 13:43:11 <michagogo> The server is up, and accepting connections on port 80...
 44 2014-09-07 15:20:39 <aburan28> hello, I am trying to work on a solution to fix the non-incentivized  full-node issue and have a few basic ideas about how I might go about that solution
 45 2014-09-07 15:20:41 <aburan28> but
 46 2014-09-07 15:21:11 <aburan28> are there any viable solutions on the table or even being considered?
 47 2014-09-07 15:23:22 <justanotheruser> aburan28: I doubt full nodes can be trustlessly incentivized due to some fundamental issues with the idea.
 48 2014-09-07 15:23:29 <aburan28> it seems that the only real way to reward fullnodes is via a seperate altcoin attached to something like the proof of bandwidth algorithm from the TorCoin paper
 49 2014-09-07 15:23:52 <aburan28> What are those fundamental issues?
 50 2014-09-07 15:24:58 <justanotheruser> aburan28: the fact that unlike generating a small hash (which is a proof that you did work), you are sending electrical impulses over a wire (which is only known to be happening by those who have access to that wire, so you, the ISPs and your peer).
 51 2014-09-07 15:25:28 <justanotheruser> so really, trust in bandwidth is a much better name for the concept
 52 2014-09-07 15:27:12 <sipa> there are two different things: full nodes provide service to the network (relay/storage of blocks/transactions), and do validation
 53 2014-09-07 15:27:23 <sipa> the last things is imho more important, but is not quantifiable
 54 2014-09-07 15:27:54 <sipa> it's just trustlessness at work... more people running full nodes and using the resulting information to build an economy
 55 2014-09-07 15:28:38 <sipa> as in: if nobody was really running a full node, miners could set whatever rules they like
 56 2014-09-07 15:28:41 <justanotheruser> as greg pointed out to me, full nodes are already incentivized because they have full node security
 57 2014-09-07 15:32:34 <aburan28> what about that scalability problem in the future? lets say 50,000tx per day were added consecutively...wouldn't there need to be some kind of distributed network to handle that load?
 58 2014-09-07 15:32:44 <jgarzik> justanotheruser, mildly incentivized
 59 2014-09-07 15:33:11 <justanotheruser> jgarzik: yeah, I'm guessing in the currenc full nodes there is a bit of altruism
 60 2014-09-07 15:33:49 <sipa> aren't we already doing 50000 tx per day?
 61 2014-09-07 15:33:57 <justanotheruser> also, there is a bitcoin noob I know who is running bitcoin-Qt on his laptop. Not sure why he would want to handle ~30kb/min, but I told him and he didn't mind it.
 62 2014-09-07 15:34:12 <aburan28> actually, let me just ask this: can the network rely on altruism to run fullnodes? or can this network survive without a large amount fullnodes?
 63 2014-09-07 15:35:00 <justanotheruser> aburan28: they are incentivized by full node security and supporting the bitcoin netork
 64 2014-09-07 15:35:23 <sipa> right, but you can get the full node security without supporting the network
 65 2014-09-07 15:35:41 <sipa> though apart from some bandwidth, there is little difference between them
 66 2014-09-07 15:35:45 <justanotheruser> sipa: how much more does it cost to support the network once you have full node security?
 67 2014-09-07 15:35:57 <sipa> exactly as much as others ask you :)
 68 2014-09-07 15:36:10 <sipa> if they ask many blocks, you'll have to read many blocks from disk and send them over the network
 69 2014-09-07 15:36:25 <justanotheruser> well I have uncapped internet, so it is all electricity and depreciating hardware
 70 2014-09-07 15:36:46 <sipa> oh, if you don't otherwise need the full blocks yourself, you could delete them if you don't want to serve them to others
 71 2014-09-07 15:37:35 <justanotheruser> yeah, I wonder how making that process easier (v0.10.0 will have sharding, no?) will effect the number of contributing full nodes
 72 2014-09-07 15:37:46 <sipa> sharding?
 73 2014-09-07 15:38:06 <sipa> no, it will likely have pruning though
 74 2014-09-07 15:38:16 <sipa> which is maybe what you meant?
 75 2014-09-07 15:38:21 <justanotheruser> I don't think so
 76 2014-09-07 15:38:38 <sipa> pruning = remove old blocks from disk after verification
 77 2014-09-07 15:39:02 <justanotheruser> Sharding means I might store blocks 50,000-150,000 and some other guy might have 1-49,999 and 150,001-.... etc
 78 2014-09-07 15:39:22 <sipa> the current pruning implementation is just all or nothing
 79 2014-09-07 15:39:27 <justanotheruser> oh
 80 2014-09-07 15:39:31 <sipa> for more advanced things, we need a protocol change
 81 2014-09-07 15:39:37 <justanotheruser> do we?
 82 2014-09-07 15:39:37 <sipa> so nodes can advertize which ranges they have
 83 2014-09-07 15:39:43 <justanotheruser> right right
 84 2014-09-07 15:39:58 <aburan28> what kind of protocol changes?
 85 2014-09-07 15:40:21 <sipa> either through a few service bits, or by an extension of the addr/version messages
 86 2014-09-07 15:40:37 <sipa> now you can just advertize "i'm a full node!" or "I'm nothing!"
 87 2014-09-07 15:40:55 <aburan28> hmmmm
 88 2014-09-07 15:41:07 <justanotheruser> sipa: couldn't that be made to be backward compatible? You would just end up with spam from a lot of old nodes asking for blocks you don't have
 89 2014-09-07 15:41:26 <sipa> justanotheruser: you getting spam is not a problem
 90 2014-09-07 15:41:31 <sipa> justanotheruser: them not getting the blocks is
 91 2014-09-07 15:41:50 <justanotheruser> right, they would probably have to query more than one node
 92 2014-09-07 15:41:56 <sipa> which they currently don't
 93 2014-09-07 15:42:16 <sipa> after headersfirst and parallel block fetching is sufficiently rolled out, that would be much less of a problem
 94 2014-09-07 15:43:24 <dgenr8> sipa: hence the p2p network is essential to the design because it channels user traffic through the validating full nodes
 95 2014-09-07 15:44:04 <sipa> dgenr8: assuming everyone is running code to validate what they consider necessary to validate, the validation others do doesn't matter
 96 2014-09-07 15:44:11 <sipa> it just prevents many dos attacks
 97 2014-09-07 15:44:31 <sipa> not saying you're wrong of course, obviously we want the network to validate things
 98 2014-09-07 15:44:50 <dgenr8> sipa: referring to your comment about keeping miners honest
 99 2014-09-07 15:45:27 <sipa> if miners wanted to be dishonest, they could try to spin up many apparent-full-nodes to convince the network that what they are mining is valid
100 2014-09-07 15:45:43 <sipa> unless people run their own validation
101 2014-09-07 15:46:02 <sipa> and that is really the only full solution - bitcoin is trustless because we validate whatever we need validated ourselves
102 2014-09-07 15:46:34 <dgenr8> aye but we should worry when a direct-to-miner network appears
103 2014-09-07 15:46:51 <sipa> it's not black and white of course; SPV nodes rely on some degree of validates etc
104 2014-09-07 15:47:24 <sipa> but in an idealized situation, the service full nodes provide is purely relay/archival, and not validation
105 2014-09-07 15:48:15 <dgenr8> then you can never say things like "miners can't decide to increase the money supply because the network will ignore them"
106 2014-09-07 15:48:38 <sipa> yes you can; because everyone will ignore those blocks because they validate them
107 2014-09-07 15:48:50 <sipa> but the validation is not a service to the network, it's just something you do locally
108 2014-09-07 15:49:21 <sipa> (and, if you do it locally anyway, it makes a lot of sense to not relay invalid things either)
109 2014-09-07 15:49:40 <dgenr8> you don't matter if everyone else believes the miners
110 2014-09-07 15:49:55 <sipa> true
111 2014-09-07 15:50:34 <sipa> but if everyone reasons that way, you wouldn't bother voting for your favorite political party, right? because just your own vote doesn't matter
112 2014-09-07 15:51:02 <dgenr8> the net result is the validating p2p network
113 2014-09-07 15:51:14 <sipa> i disagree
114 2014-09-07 15:51:25 <sipa> bitcoin could start relaying every block, including invalid ones
115 2014-09-07 15:51:31 <sipa> and nothing would change, except dos potential
116 2014-09-07 15:51:43 <sipa> why? because everyone is still validating them
117 2014-09-07 15:51:56 <sipa> the economic power of those validating the rules they agree about are necessary is what sets the bitcoin rules
118 2014-09-07 15:52:26 <sipa> relaying is a service to the network, and if others choose to trust you - then yes, validation is a service to the network to
119 2014-09-07 15:52:30 <sipa> but others shouldn't be trusting you
120 2014-09-07 15:52:41 <sipa> (just talking full nodes)
121 2014-09-07 15:59:33 <dgenr8> suppose everyone could run a private full validating nodes and NOT share txes or blocks.  this would be an improvement?
122 2014-09-07 16:01:26 <sipa> they would still have to relay them; i'm just saying they don't need to guarantee validity, as others can't rely on that validity anyway
123 2014-09-07 16:01:58 <sipa> i'm not suggesting any change at all - it is really how things work today
124 2014-09-07 16:02:13 <dgenr8> oh, agreed on that.  sometimes it is said though that the p2p network is a separable or superfluous feature
125 2014-09-07 16:02:19 <sipa> i'm just saying that you shouldn't exaggerate the importance of _verified_ data
126 2014-09-07 16:02:37 <sipa> the service that full node provide is relaying
127 2014-09-07 16:02:39 <dgenr8> quite agreed, actually there really is no such guarantee even offered
128 2014-09-07 16:02:55 <sipa> not necessarily relaying validated things
129 2014-09-07 16:03:28 <sipa> however, the validation is still important - not as a service to the network, but to keep the system healthy
130 2014-09-07 16:05:24 <dgenr8> sipa: hmmmm <sipa> ... full nodes provide service to the network ... and do validation
131 2014-09-07 16:05:24 <dgenr8> <sipa> the last things is imho more important, but is not quantifiable
132 2014-09-07 16:06:21 <sipa> it's important that people verify for themselves whether the network is following the rules
133 2014-09-07 16:06:31 <sipa> or at least, that people are able to verify
134 2014-09-07 16:11:10 <dgenr8> aburan28: maybe if a tx pays you, you could sent it to nodes when you first see them.  or would this be dos?
135 2014-09-07 16:12:04 <sipa> dgenr8: ?
136 2014-09-07 16:12:10 <sipa> we already relay transactions...
137 2014-09-07 16:12:29 <aburan28> if every block (invalid/valid) was relayed to all the nodes connected you would DoS most peoples connections < 10Mbps
138 2014-09-07 16:13:48 <aburan28> man, changes to the core Bitcoin protocol are so mentally draining
139 2014-09-07 16:13:51 <dgenr8> sipa: i'm saying on inbound connect, push the "high-priority" txes out
140 2014-09-07 16:14:40 <sipa> dgenr8: if they want to, they can already fetch them
141 2014-09-07 16:14:58 <dgenr8> but they don't know they exist
142 2014-09-07 16:15:04 <sipa> getmempool
143 2014-09-07 16:15:17 <dgenr8> this is on the topic of how a fullnode could get paid.
144 2014-09-07 16:15:22 <sipa> i know
145 2014-09-07 16:15:32 <sipa> but i don't understand what your suggestion has anything to do with that
146 2014-09-07 16:15:52 <sipa> first of all, the most important thing is that people are validating the chain
147 2014-09-07 16:15:56 <sipa> but you can't observe that
148 2014-09-07 16:16:34 <sipa> second, relaying/archiving blocks/tx... you can make that a for-fee feature, but i doubt now is the right time for that
149 2014-09-07 16:17:10 <dgenr8> yeah, full node inspects tx and sees that full node itself is paid.  so it pushes it to newly connecting nodes that it normaly wouldn't push it to.
150 2014-09-07 16:17:22 <dgenr8> actually if its running a wallet i guess it does that subject to the rebroadcast rules
151 2014-09-07 16:18:32 <aburan28> what if we introduced a new type of onion-based encryption scheme to the tx message such that a sender would negotiate a txfee to pay in order to have that node add n layers of onion encryption which would decay as it propagates across the network much like the TCP ttl gets decremented
152 2014-09-07 16:18:59 <aburan28> and in effect hide the tx source
153 2014-09-07 16:19:07 <sipa> then people would set up centralized nodes to relay  things
154 2014-09-07 16:19:29 <dgenr8> your network just got better
155 2014-09-07 16:19:45 <sipa> if you want onion routing, use tor
156 2014-09-07 16:21:03 <aburan28> bitcoin has serious anonymity problems.
157 2014-09-07 16:25:08 <ThomasZ> aburan28: yet, its still magnitudes better than other solutions (like banks :)
158 2014-09-07 16:25:12 <ThomasZ> aburan28: slow steps.
159 2014-09-07 16:26:21 <aburan28> Let me state that I don't believe that there should be major changes to the bitcoin protocol as it is. But,
160 2014-09-07 16:26:38 <aburan28> I am mainly talking about overlay networks
161 2014-09-07 16:30:35 <ThomasZ> aburan28: would agree that this is good going forward.  I personally don't see that as something that falls in the scope of bitcoin.
162 2014-09-07 16:31:35 <ThomasZ> solving it at a lower level makes sense.
163 2014-09-07 16:32:17 <aburan28> yeah sorry for the confusion, just I am not trying to get an opinion from the BitMessage, Auroracoin ppl
164 2014-09-07 21:21:28 <sipa> GITHUB HAS SIDE-BY-SIDE DIFFS!
165 2014-09-07 21:21:50 <sipa> (there's a 'Unified' button, with a 'Split' next to it; click it)
166 2014-09-07 21:54:19 <gmaxwell> saivann_: I'm not happy with that bitcoin.org pull from trezor calling itself the highest level of security yadda yadda. There is no way with how the trezor currently works for you to be confident that the unit you recieved isn't using a rigged RNG for its key generation.
167 2014-09-07 21:55:19 <gmaxwell> When its so easy to poke holes at the security it certantly shouldn't be getting language like that.
168 2014-09-07 22:03:26 <petertodd> michagogo: dust-b-gone isn't a particularly good idea - better to just not spend the dust. UTXO "bloat" is a non-issue better solved with a fixed size UTXO set and TXO commitments.
169 2014-09-07 22:04:29 <sipa> petertodd: having some idea about how a scalability concern may be addressed in the future is no reason not to care about it at all anymore
170 2014-09-07 22:05:07 <petertodd> sipa: it's harmful because it encourages not addressing the scalability concern, which is equally an economic exploit
171 2014-09-07 22:05:29 <petertodd> sipa: also, it's a enormous waste of time given the amount of usage it gets
172 2014-09-07 22:05:47 <sipa> both the long term and short term future matter
173 2014-09-07 22:06:11 <petertodd> with the amount of usage it gets, the short term *definitely* doesn't matter
174 2014-09-07 22:06:31 <sipa> maybe; probably depends on your definition of 'short'
175 2014-09-07 22:07:05 <sipa> i'm not opposed to TXO commitments and other measures to make the size of the UTXO set less of an issue
176 2014-09-07 22:07:15 <sipa> but i don't know how the future will look by the time we get there
177 2014-09-07 22:08:02 <petertodd> the % of the UTXO set that dust-b-gone would be getting rid of even in the best circumstance is trivial
178 2014-09-07 22:08:06 <christophe> gmaxwell: You can combine with host-computer provided entropy.
179 2014-09-07 22:08:35 <sipa> petertodd: i agree about that
180 2014-09-07 22:09:01 <sipa> petertodd: i'm just annoyed by that "this is a problem that is solved in theory; so let's forget about it" mentality
181 2014-09-07 22:09:13 <petertodd> sipa: besides, gmaxwell promised $100 from the coinjoin fund for it and never paid up :P
182 2014-09-07 22:11:07 <gmaxwell> christophe: You cannot: if the device is malicious it will simply ignore (or otherwise leak) 'host-computer provided entropy'. You have no way to tell that it is included.
183 2014-09-07 22:11:42 <petertodd> sipa: in a saner situation, that'd be a valid concern, but bitcoin has politics to deal with and getting consensus that economic issues need to be solved is damn hard
184 2014-09-07 22:12:25 <gmaxwell> petertodd: I just haven't done any payout of the coinjoin fund, I'll pay out of that when it goes. :) (I was trying to do a bit of a payout for darkwallet, but their stuff is just not working on testnet at all and they went unresponsive when I tried to follow up on it with them. :( (I assume they're just busy.))
185 2014-09-07 22:13:06 <petertodd> gmaxwell: I'm in london next week and will have a chance to bring it up with them in person
186 2014-09-07 22:13:16 <frankster> q
187 2014-09-07 22:13:28 <sipa> petertodd: and not having dust-b-gone will definitely cause people to see the economic issues behind utxo sizes faster? :)
188 2014-09-07 22:13:46 <gmaxwell> petertodd: so far all designs for txo commitments trade bandwidth for storage, which seems to be entirely the wrong tradeoff. :(
189 2014-09-07 22:13:49 <petertodd> gmaxwell: be good to get easy instal instructiosn for the obelisk servers to have some more third parties running them for instance
190 2014-09-07 22:14:05 <gmaxwell> in any case, dust-b-gone is also useful for reducing the privacy loss from dust.
191 2014-09-07 22:14:20 <petertodd> sipa: yes, dust-b-gone gets brought up as one of the reasons why UTXO set size doesn't matter
192 2014-09-07 22:14:29 <christophe> gmaxwell: for audit purposes, you can get it to show the internal entropy on its screen before the host provides its half so that you can take both and verify the math is done properly.
193 2014-09-07 22:14:37 <gmaxwell> petertodd: lol it certantly shouldn't be brought up as an example of that.
194 2014-09-07 22:14:45 <christophe> At that point, all that's left is side-channel leaks.
195 2014-09-07 22:16:00 <petertodd> gmaxwell: the bandwidth/storage tradeoff is always only a theoretical one; you would want to still keep your UTXO set so it's only very old UTXOs getting spent that incurs any bandwidth penalty
196 2014-09-07 22:16:20 <petertodd> gmaxwell: of course, you can makea solid argument that having UTXO commitments at all will make UTXO bloat worse...
197 2014-09-07 22:16:52 <gmaxwell> christophe: When I saw it before the device could tell you were doing that.  I found it very concerning that there was no secure way to initilize it with something like dicewords; esp with the decision to not support multisig.
198 2014-09-07 22:17:23 <petertodd> gmaxwell: dust-b-gone is a strict reduction in privacy compared to just not spending the dust at all
199 2014-09-07 22:17:44 <gmaxwell> petertodd: not spending it isn't actually what people do, however.
200 2014-09-07 22:18:00 <gmaxwell> also, not spending it has resulted in ltc having a 1gb utxo set.
201 2014-09-07 22:18:19 <gmaxwell> (even though it has something like 100th the amount of usage of bitcoin or less)
202 2014-09-07 22:18:37 <gmaxwell> I thought you'd been paid to fix ltc's problems? :)
203 2014-09-07 22:18:57 <sipa> i think he was paid to find them
204 2014-09-07 22:19:42 <petertodd> gmaxwell: yes, and I gave the money back and canceled the contract because we decided the solution was a bad idea
205 2014-09-07 22:19:46 <gmaxwell> ah!
206 2014-09-07 22:19:57 <gmaxwell> I thought the solution you were going to do was utxo commitments for the old dust?
207 2014-09-07 22:20:17 <petertodd> gmaxwell: well, that and the other part of the solution was something sipa was working on more than me - once it got implemented I wouldn't deserve the money anyway
208 2014-09-07 22:20:32 <petertodd> gmaxwell: no, the solution was to do a soft-fork and remove it from the UTXO set - huge amount of effort for a trivial one-time thing
209 2014-09-07 22:21:09 <gmaxwell> petertodd: hm. Okay, I'll have to think more about the utxo commitment only for old/low value utxo. Perhaps that really does split the bad tradeoff for more bandwidth.
210 2014-09-07 22:21:25 <petertodd> gmaxwell: *txo* commitment only for old/low value
211 2014-09-07 22:22:08 <gmaxwell> uh. txo requires a seperate search query on spentness.
212 2014-09-07 22:22:31 <petertodd> gmaxwell: ?
213 2014-09-07 23:27:03 <michagogo> petertodd: someone sent 1000 satoshis to a whole bunch of gribble bc auth addresses
214 2014-09-07 23:27:28 <michagogo> I don't like having little bits of dust around, especially when
215 2014-09-07 23:27:41 <michagogo> they're bits of dust that explicitly identify me