1 2012-08-20 00:02:15 lunchtime has joined
   2 2012-08-20 00:02:31 luncht1me has quit (Quit: —I-n-v-i-s-i-o-n— 3.3 (November '11) , You know what time it is)
   3 2012-08-20 00:02:39 lunchtime has quit (Read error: Connection reset by peer)
   4 2012-08-20 00:03:14 lunchtime has joined
   5 2012-08-20 00:04:06 lunchtime has quit (Read error: Connection reset by peer)
   6 2012-08-20 00:04:53 <amiller> i think the thing to do is to build a redblack tree using a 'zipper monad'
   7 2012-08-20 00:05:19 <amiller> the reason why is that i can compose it with a 'memoize monad' which would let me implement whatever caching policy i need
   8 2012-08-20 00:07:09 <amiller> i know of a haskell red-black tree using a zipper, but a) it doesn't use the monadic style so i'd have to rewrite it in order to compose with memo-monad, b) it didn't implement the "delete" half of redblack tree, and c) i'd have to add the 'digest' computation
   9 2012-08-20 00:08:41 <roconnor> amiller: use a Patrica Trie
  10 2012-08-20 00:08:52 <roconnor> it has a canonical shape
  11 2012-08-20 00:08:58 <amiller> roconnor, do you think a patricia will work as a hash tree
  12 2012-08-20 00:08:59 <roconnor> for a given data set
  13 2012-08-20 00:09:11 <amiller> how would you augment a patricia trie with hashes
  14 2012-08-20 00:09:24 <roconnor> I rejected balanced binary trees because they depend on what order things are inserted and deleted
  15 2012-08-20 00:09:45 <amiller> etotheipi has been trying to convince me of exactly that point for weeks now.
  16 2012-08-20 00:09:57 <roconnor> listen to him :)
  17 2012-08-20 00:10:18 <amiller> i don't understand why that insertion order is important? and in either case, what's stopping both of us is i don't see how to implement a patricia trie with hashes efficiently
  18 2012-08-20 00:11:04 <sipa> a binary patricia tree, with each node containing both hashes of the subnodes
  19 2012-08-20 00:11:12 <sipa> shouldn't be too hard
  20 2012-08-20 00:11:21 <sipa> as it's essentially automatically balanced
  21 2012-08-20 00:11:32 <roconnor> sipa: not automatically
  22 2012-08-20 00:11:49 <sipa> although it can have theoretically depth 256
  23 2012-08-20 00:12:15 <roconnor> patricia tree are expected to be balanced given random keys
  24 2012-08-20 00:12:30 <sipa> but in practice any depth over 2*log(2) should be vanishingly small
  25 2012-08-20 00:12:46 <sipa> *probability for
  26 2012-08-20 00:13:16 <amiller> that randomness is probably pretty close to what would be the typical scenario
  27 2012-08-20 00:13:16 <sipa> which is as good as red-black tree
  28 2012-08-20 00:13:47 <roconnor> amiller: yes, which is why you should use a patrica trie
  29 2012-08-20 00:14:06 <amiller> can you explain why insertion order independence matters for bitcoin?
  30 2012-08-20 00:14:14 <amiller> if you have a block, you have the hash of the previous tree as well
  31 2012-08-20 00:14:27 <amiller> etotheipi has been stuck trying to explain to me why it's important
  32 2012-08-20 00:14:42 <roconnor> amiller: we are talking about a tree of unspent coins, right?
  33 2012-08-20 00:14:48 <amiller> yes
  34 2012-08-20 00:15:03 <sipa> in case of reorgs, the order can depend on the history
  35 2012-08-20 00:15:25 <sipa> as not all nodes have necessarily seen the reorg
  36 2012-08-20 00:15:26 <roconnor> amiller: it is so that you will create the correct tree just given the data of the tree.
  37 2012-08-20 00:15:34 <amiller> but if you have a reorg, wherever the fork point is, you have the hash of the tree at that point
  38 2012-08-20 00:15:47 <amiller> you create the correct tree, given the block where the forkpoint is
  39 2012-08-20 00:15:48 <roconnor> amiller: the reason is defensive programming
  40 2012-08-20 00:16:15 <sipa> yes, it's just a nice property that the hash only depends on the utxo set, and nothing else
  41 2012-08-20 00:18:02 bitcoinbulletin has quit (Quit: bitcoinbulletin)
  42 2012-08-20 00:18:28 <roconnor> for a protocol, especially of the nature of bitcoin, you want the number of non-essential programming choices to be as small as possible so that you are more likely to have implementor impelement the spec correctly.
  43 2012-08-20 00:18:55 <roconnor> Following Murphy's law: anything that can go wrong, will go wrong.
  44 2012-08-20 00:18:56 <sipa> wwe have way too many arbitrary-sounding rules already
  45 2012-08-20 00:19:10 <amiller> i hope you'll let me match that somewhat-weak point with another weak-point
  46 2012-08-20 00:19:14 <roconnor> when designing something you want to make sure that nothing can go wrong, because if it can go wrong, it will go wrong.
  47 2012-08-20 00:19:16 <amiller> the patricia trie has a poor worst-case guarantee
  48 2012-08-20 00:19:23 <amiller> and even though the utxos are likely to be random
  49 2012-08-20 00:19:34 <amiller> since people have control over their addresses, it would still be vulnerable to the worst-case
  50 2012-08-20 00:19:44 <amiller> and the problem with defensive programming is that you're constrained by the worst _plausible_ validation effort
  51 2012-08-20 00:19:52 <sipa> attacking it costs hashing power
  52 2012-08-20 00:20:04 <roconnor> e.g. make sure your accellormeters can only be inserted one way: http://r6.ca/blog/20050928T195400Z.html
  53 2012-08-20 00:20:05 <amiller> someone could _tell_ you that you need to validate a very unbalanced merkle trie and you'd have to expend more effort to show it's wrong
  54 2012-08-20 00:20:48 <amiller> with the red black tree, you have a firm worst-case 2*log N (or something near that) that lets you reject quickly
  55 2012-08-20 00:21:20 <roconnor> well the worse case depth is only 256 checks;  I personally consider it an acceptable trade-off.  But it is probably a matter of opinion.
  56 2012-08-20 00:21:31 <sipa> 160 actually
  57 2012-08-20 00:21:45 <sipa> if someone manages to create a collision on 160 bits, bitcoin is dommed
  58 2012-08-20 00:21:50 <sipa> *doomed
  59 2012-08-20 00:22:05 <sipa> sorry, preimage
  60 2012-08-20 00:22:09 <sipa> never mind
  61 2012-08-20 00:22:11 ultrixx has joined
  62 2012-08-20 00:22:27 <amiller> a txout is 256+8
  63 2012-08-20 00:22:28 <sipa> here the problem is collisions, which is a lot easier than preimages
  64 2012-08-20 00:22:42 <sipa> my utxo set is only indexed by txid
  65 2012-08-20 00:22:43 <amiller> and if you want to include a search index for addresses, then the keys are 160+256+8
  66 2012-08-20 00:23:18 <amiller> sipa, yes but then you would need auxiliary information that you couldn't validate just given a root hash
  67 2012-08-20 00:23:29 <sipa> amiller: such as?
  68 2012-08-20 00:24:46 <amiller> if all i have is the root hash, and all i learn from querying the tree is that there exists an unspent output in txid=xxxx, then i would still have to rescan the chain to see which txout(s) are unspent
  69 2012-08-20 00:25:24 <sipa> the value contains the actual txouts
  70 2012-08-20 00:25:32 <sipa> but those are not part of the key
  71 2012-08-20 00:26:42 <phantomcircuit> DiabloD3, any chance you'd be willing to write a gpu based vanity generator for tor .onion addresses?
  72 2012-08-20 00:26:52 <phantomcircuit> the existing cpu implementation leaves something to be desired
  73 2012-08-20 00:27:00 <sipa> so i compromise the efficiency of looking up a utxo (by requiring a linear search of the value in the txid->utxos map), for improved storage
  74 2012-08-20 00:27:20 <sipa> as some data is shared for all utxos of one tx
  75 2012-08-20 00:27:47 bitcoinbulletin has joined
  76 2012-08-20 00:27:57 <amiller> but it's an unnecessary compromise, you can take advantage of compressed storage anyway regardless of how the hashes are combined
  77 2012-08-20 00:28:09 <sipa> how so?
  78 2012-08-20 00:28:30 bdcs has quit (Ping timeout: 245 seconds)
  79 2012-08-20 00:28:37 <amiller> well for example you can store just the bitvector for the utxos
  80 2012-08-20 00:28:59 <sipa> (my utxo data so contains the height of each tx, for example)
  81 2012-08-20 00:29:04 <sipa> *also
  82 2012-08-20 00:29:34 <amiller> let me put it this way
  83 2012-08-20 00:29:56 <amiller> hrm
  84 2012-08-20 00:30:18 <amiller> basically you could store two trees, one of them just contains the binary tree of hashes, and the other just contains the trie of data without hashes
  85 2012-08-20 00:30:36 <sipa> ok
  86 2012-08-20 00:30:38 <sipa> yes
  87 2012-08-20 00:30:54 <DiabloD3> [08:21:08] <phantomcircuit> DiabloD3, any chance you'd be willing to write a gpu based vanity generator for tor .onion addresses?
  88 2012-08-20 00:30:57 <DiabloD3> there already is one
  89 2012-08-20 00:31:10 <phantomcircuit> is there? i could only find the cpu one
  90 2012-08-20 00:31:25 <phantomcircuit> shallot is the only one i could fine
  91 2012-08-20 00:31:27 <phantomcircuit> find
  92 2012-08-20 00:32:29 <amiller> yeah i don't know where to go from there, it wasn't such a clear thought
  93 2012-08-20 00:32:31 bdcs has joined
  94 2012-08-20 00:32:36 <DiabloD3> phantomcircuit: someone ported shallot to gpu
  95 2012-08-20 00:32:47 <DiabloD3> its on github somewhere
  96 2012-08-20 00:32:54 bdcs is now known as Guest63372
  97 2012-08-20 00:33:01 <sipa> amiller: my design decision was made partly becaus the current database layer (bdb, or later maybe levelfb), stores keys and values completely
  98 2012-08-20 00:33:45 <sipa> so i didn't want to store the txids (which are effectively like 35-40% of thr serialized data)
  99 2012-08-20 00:33:52 <sipa> multiple times
 100 2012-08-20 00:34:59 <amiller> that doesn't seem like a concern that should be reflected in the normative specification though
 101 2012-08-20 00:35:12 <sipa> the original point of ultraprune was actually not to rewrite the validation engine, but just to have an idea of how small the utxobset would be
 102 2012-08-20 00:35:12 <amiller> if you find a better compressing database then it won't matter
 103 2012-08-20 00:35:49 <amiller> it's different when we're talking about committing to a particular structure in a blockchain, especially for lite clients with minimal trusted storage
 104 2012-08-20 00:36:22 <amiller> like putting a trie in the normative protocol makes storage/implementation superficially easier, but it exposes lite clients to worse plausible-validation ddos attacks
 105 2012-08-20 00:37:37 <sipa> with the work currently performed by the entire bitcoin network, you could have some chance at grtting a collision of 140 bits
 106 2012-08-20 00:37:39 <amiller> putting a balanced binary tree in the normative protocol means you'll need to use a compression heuristic or something, but the information complexity is the same for random data, and lite clients have a better "firm reject" limit
 107 2012-08-20 00:38:45 RainbowDashh has quit (Quit: Computer has gone to sleep.)
 108 2012-08-20 00:38:48 <phantomcircuit> DiabloD3, lol even knowing it's there i still cant find it
 109 2012-08-20 00:38:48 <amiller> sipa, in order for your point to be applicable, you would have to be talking about making a "hard reject rule" that doesn't check past 140 bits - that is actually weakening your security level to that number of bits
 110 2012-08-20 00:38:51 <sipa> well, if the balanced tree implementation is over 8 times slower than the patricia system (just a constant factor), that point becomes invalid :)
 111 2012-08-20 00:39:02 <DiabloD3> phantomcircuit: weird
 112 2012-08-20 00:39:28 <roconnor> in theory patrica tree lookups can be pretty fast
 113 2012-08-20 00:39:47 <sipa> because 40 bit collisions will occur in a current patricia tree, and 40 levels will happen in redblack trees too
 114 2012-08-20 00:40:01 <amiller> roconnor, when you say that, are you thinking about patricia "Merkle" tree lookups, including validating a hash at each bit?
 115 2012-08-20 00:40:11 <roconnor> amiller: no
 116 2012-08-20 00:41:23 <phantomcircuit> DiabloD3, #tor oftc people say it doesn't exist
 117 2012-08-20 00:41:30 <phantomcircuit> who is right? FIGHT TO THE DEATH
 118 2012-08-20 00:42:13 <sipa> amiller: so the worst case difference is at most a constant factor 6
 119 2012-08-20 00:42:39 <sipa> and that is assuming a 2^256 step attack, which would kill bitcoin anyway
 120 2012-08-20 00:42:46 <phantomcircuit> DiabloD3, lol the cpu based one is a fucking mess
 121 2012-08-20 00:42:49 <phantomcircuit> it keeps seg faulting
 122 2012-08-20 00:42:57 <phantomcircuit> race conditions everywhere
 123 2012-08-20 00:43:05 <amiller> so what's the case hit to the compressibility of the data?
 124 2012-08-20 00:43:10 <amiller> since that ultimately determines the storage cost
 125 2012-08-20 00:43:22 <amiller> i'd argue that the compressibility of the data is unaffected
 126 2012-08-20 00:43:23 <sipa> amiller: that's a more interesting question
 127 2012-08-20 00:43:51 <amiller> http://www.cs.uni-paderborn.de/fileadmin/Informatik/FG-TI/Christian/Publications/HashedPatriciaTrie.pdf here's a paper on patricia hash tries, maybe i'll find some insight in there
 128 2012-08-20 00:44:30 Titanium has joined
 129 2012-08-20 00:44:45 <amiller> nevermind this doesn't use hashes for security at all, it's a different idea altogether
 130 2012-08-20 00:45:07 <roconnor> sipa: compressability?
 131 2012-08-20 00:45:25 <amiller> i'm pretty sure that any advantage of a patricia trie melts away when you implement a merkleized version you can commit to in a block, but i'm not sure how else to defend that statement
 132 2012-08-20 00:45:48 enquirer has joined
 133 2012-08-20 00:47:35 <sipa> amiller: i don't care about a particular structure, but i agree with roconnor that a deterministic system, that only allows one structure (and thus one root hash) per data set, is an important property
 134 2012-08-20 00:48:04 <sipa> and more loosely defined structures will almost certainly be more efficient, as they require less rebalancing
 135 2012-08-20 00:48:31 <sipa> but that difference should at most be a constant factor anyway
 136 2012-08-20 00:49:26 <amiller> well that puts me entirely by myself in the balanced binary tree camp.
 137 2012-08-20 00:49:57 <sipa> fully-balanced binary trees also have that property :)
 138 2012-08-20 00:50:56 <amiller> i think what we would need to do to resolve this is to specify what it is that matters about having order independnece
 139 2012-08-20 00:51:37 <sipa> it has the advantage that you can just send a list of txouts to someone and they can construct the correct tree from it
 140 2012-08-20 00:51:37 <amiller> if you attempt to state that clearly, i think you'll find that it puts the cart in front of the horse, because it begins with "given you have an O(N) set of trusted utxo data, you can compute the O(1) root hash"
 141 2012-08-20 00:52:03 <amiller> if you can send them a list of txouts, and they trust you,
 142 2012-08-20 00:52:41 <amiller> then you could send them the txouts, plus another N of structure for the binary tree, and then they compute the correct tree from it just as easily
 143 2012-08-20 00:52:50 denisx has quit (Quit: denisx)
 144 2012-08-20 00:53:02 <amiller> in any case, they will have to _trust_ you to send an entire list of txouts, which is not the important scenario
 145 2012-08-20 00:53:14 <amiller> the important scenario is when you only want to send them O(1) if they have to trust it
 146 2012-08-20 00:53:30 <roconnor> for me it is about reducing programming errors in implemenations.
 147 2012-08-20 00:53:42 tsche has quit ()
 148 2012-08-20 00:54:38 <sipa> i think it would just be wrong to require that for someone to verify the UTXO set, they need to know in which order it was created
 149 2012-08-20 00:54:51 <sipa> that sounds not what we're trying to do
 150 2012-08-20 00:54:59 <amiller> they don't need to know which order it was created, but they need to know the tree structure
 151 2012-08-20 00:55:04 <sipa> agree
 152 2012-08-20 00:55:06 <amiller> not even all the hashes in the tree structure, just the tree structure
 153 2012-08-20 00:55:13 <amiller> they can recompute the hashes in this scenario
 154 2012-08-20 00:55:21 <sipa> agree, but why require that data?
 155 2012-08-20 00:55:34 <amiller> you're picking the strangest of all scenarios
 156 2012-08-20 00:55:40 <amiller> you don't require all that data
 157 2012-08-20 00:55:47 <amiller> because if you can send them trusted data, just send them the root hash and you're done
 158 2012-08-20 00:56:03 RainbowDashh has joined
 159 2012-08-20 00:56:20 <sipa> the trees will still have to be transferred somehow
 160 2012-08-20 00:56:30 <sipa> to bootstrap, for example
 161 2012-08-20 00:56:34 Maccer has quit (Excess Flood)
 162 2012-08-20 00:56:41 <amiller> the trees will not have to be trasnferred over a trsuted channel
 163 2012-08-20 00:56:49 <phantomcircuit> DiabloD3, hmm so for an onion generator you need to generate a bunch of rsa key pairs and then hash the public key
 164 2012-08-20 00:56:52 <amiller> once they have the root hash, they can scavenge the rest from the internet
 165 2012-08-20 00:57:09 dvide has quit ()
 166 2012-08-20 00:57:25 <sipa> amiller: yes, indeed, but they still have to
 167 2012-08-20 00:57:34 <amiller> even then, when you say 'have to'
 168 2012-08-20 00:57:56 <amiller> have to in order to do what? to be bootstrapped? if they have the O(1) hash they're already boostrapped because they can query just the parts of the tree they are interested in
 169 2012-08-20 00:58:23 <sipa> in one scenario, yes
 170 2012-08-20 00:58:42 <sipa> but certainly a validating node will want the entire set anyway
 171 2012-08-20 00:58:54 <amiller> in the scenario where you transfer O(N) of trusted information, then the entire tree is still O(N)
 172 2012-08-20 00:59:14 <amiller> in the scenario where you transfer O(1) trusted information, then you don't need the O(N) data
 173 2012-08-20 00:59:15 <sipa> yes, we're just discussing constant factors anyway
 174 2012-08-20 00:59:24 <sipa> in both cases
 175 2012-08-20 01:00:04 <sipa> but it still feels wrong to me that the history of the utxo set has an influence on its hash
 176 2012-08-20 01:01:39 <sipa> as that does force you to keep old states of the utxo tree, or undo data that includes structural information about the tree
 177 2012-08-20 01:01:57 <amiller> those are needed for reorgs anyway
 178 2012-08-20 01:01:57 <sipa> instead of just being able to construct that undo data from the block chain
 179 2012-08-20 01:02:07 <roconnor> ah right
 180 2012-08-20 01:02:11 <roconnor> that was a problem
 181 2012-08-20 01:02:13 <amiller> you can't construct the undo data from the blockchain anyway
 182 2012-08-20 01:02:21 <amiller> you'd have to construct the undo data from an incrementally modified utxo
 183 2012-08-20 01:02:26 <sipa> right, you need the utxo set for that
 184 2012-08-20 01:02:29 <amiller> unless you lookup the utxo by its hash, but that's what i'm saying you can do anyway
 185 2012-08-20 01:02:48 <sipa> but you don't need the utxo tree strucure for that
 186 2012-08-20 01:03:20 <amiller> if you're doing the incremental update, then the additional tree structure is no additional burden
 187 2012-08-20 01:03:31 <amiller> if you aren't doing the incremental update, then what matters is that you have a root hash, not the structure underneath it
 188 2012-08-20 01:03:36 iocor has quit (Quit: Computer has gone to sleep.)
 189 2012-08-20 01:04:04 <sipa> wel, this sounds trivial: if the tree structure is defined by the set, then obviously patch data for it will not require any structural information, but only set modification data
 190 2012-08-20 01:05:18 <amiller> if that's what "feels wrong" then it's a constant factor
 191 2012-08-20 01:05:21 Turingi has quit (Read error: Connection reset by peer)
 192 2012-08-20 01:05:36 <roconnor> The problem was that I wanted (the option) to store only the unspent tree at the node of the tree with the highest work, and be able to zip it down and back up during a reorg; storing only the transaction deltas at the internal nodes of the block tree.
 193 2012-08-20 01:05:42 <sipa> feels wrong is not a strong argument of coutse
 194 2012-08-20 01:05:55 <amiller> to me, having worst-case validation costs go up by a constant factor is a bigger priority than having incremental update costs go up
 195 2012-08-20 01:06:49 <amiller> roconnor, you might enjoy my post about the Hash-Value-Highway since it sounds a bit like that
 196 2012-08-20 01:06:57 <sipa> but an attacker has to spend exponentially more work, to get a linear effect on validation hardnrss
 197 2012-08-20 01:07:06 <amiller> it's a skip list, it lets you zip around to the highest work blocks
 198 2012-08-20 01:07:33 Marf has quit (Ping timeout: 246 seconds)
 199 2012-08-20 01:07:42 <amiller> sipa, i don't think that's true in this case
 200 2012-08-20 01:08:03 ultrixx has left ("Verlassend")
 201 2012-08-20 01:08:07 <amiller> because when you query the tree, it's not like you validate the transactions at the bottom
 202 2012-08-20 01:08:56 <amiller> i think we agree that the costs here are about one constant factor that feels bad in one location, vs the same constant factor in another location that feels bad for a different reason
 203 2012-08-20 01:09:17 <sipa> the constant factor isn't what bothers me
 204 2012-08-20 01:09:25 <sipa> it is the dependence on history
 205 2012-08-20 01:10:05 <amiller> the hash of the current head is fully dependent on the entire history of the blockchain
 206 2012-08-20 01:10:05 bitcoiner has joined
 207 2012-08-20 01:10:19 <sipa> i'm just arguing that the side effect for preventing this dependence on history is limited
 208 2012-08-20 01:10:36 <sipa> but the order in the blockchain is somethinh relevant
 209 2012-08-20 01:10:49 <sipa> the order in which utxo set uodates were performed isnt
 210 2012-08-20 01:11:16 <roconnor> indeed you are no longer hashing the utxo set; you are hashing the utxo set plus some more stuff.
 211 2012-08-20 01:12:33 <sipa> and you can use a fully balanced binary tree too
 212 2012-08-20 01:12:49 <sipa> that is deterministic, and has perfect worst case. behaviour
 213 2012-08-20 01:12:57 <sipa> but still higher constant factors
 214 2012-08-20 01:13:23 <amiller> i don't think there's any fully balanced binary tree that has worst-case updates
 215 2012-08-20 01:13:24 <sipa> as you can potentially have many rebalancing steps
 216 2012-08-20 01:13:49 <sipa> that statement doesn't make sense?
 217 2012-08-20 01:14:00 <amiller> like what i'm concerned about is whichever is worse, the worst-case query cost or the worst-case update cost
 218 2012-08-20 01:14:39 <amiller> anyway i think it's interesting that you said that the constant factor isn't what bothers you
 219 2012-08-20 01:14:45 <sipa> a lot depends probably on how you expect this datastructure to fit in a mkre complex system, and how it will be used
 220 2012-08-20 01:14:51 <amiller> you're saying that you have an uneasy feeling about order independence that goes beyond a constant factor
 221 2012-08-20 01:14:56 <sipa> yes
 222 2012-08-20 01:15:01 <amiller> but every example you can give me about how the trie behaves differently
 223 2012-08-20 01:15:07 <amiller> is only worse by a constant factor in cost
 224 2012-08-20 01:16:21 <sipa> if i have the utxo set, then i only want to need 1 hash to know it is correct
 225 2012-08-20 01:16:51 <sipa> even if i don't know the order of operations that resulted in this set
 226 2012-08-20 01:17:31 <amiller> you don't. if you have the utxo set, i'm not saying you need to also know the order of operations, i'm saying you also need the 'tree structure' which is very small
 227 2012-08-20 01:17:52 <amiller> it's a constant factor
 228 2012-08-20 01:18:14 <amiller> the order of operations is only relevant when you don't have the utxo because you're iterating from scratch anyway
 229 2012-08-20 01:18:45 <amiller> if i download your UTXO, i'm getting a BTree.
 230 2012-08-20 01:19:08 RainbowDashh has quit (Quit: Computer has gone to sleep.)
 231 2012-08-20 01:19:09 <sipa> well, we're discussing an uneasy feeling, and you're not going to change that with a rational argument before i think about it more myself
 232 2012-08-20 01:19:43 <amiller> whatever it is that's making you feel uneasy, roconnor etotheipi gmaxwell and you must have all eaten the same thing :/
 233 2012-08-20 01:19:58 <sipa> afaik, we all have different reasons
 234 2012-08-20 01:20:08 <phantomcircuit> DiabloD3, it'll be interesting to see how long it takes to generate a "bitcoin" vanity address on a i3-2100
 235 2012-08-20 01:20:23 <amiller> well yours match etotheipi's very closely
 236 2012-08-20 01:20:41 <sipa> hell no, i think indexing on addresses is overkill :)
 237 2012-08-20 01:21:40 <sipa> or at least non-essential
 238 2012-08-20 01:21:57 <amiller> your UTXO uses a btree right now right
 239 2012-08-20 01:22:09 <DiabloD3> phantomcircuit: heh
 240 2012-08-20 01:22:17 <amiller> suppose i could turn a bdb utxo btree into the same redblack tree that my algorithm produces
 241 2012-08-20 01:22:20 <jgarzik> but but... if we indexed on addresses, we could turn bitcoin into a balance sheet database, and ditch the history!
 242 2012-08-20 01:22:22 * jgarzik runs
 243 2012-08-20 01:22:48 <sipa> amiller: bdb is a b+ tree i suppose, with a large fanout
 244 2012-08-20 01:23:04 D34TH has quit (Quit: Leaving)
 245 2012-08-20 01:23:09 <sipa> but from the semantics point of view, i have a set and no tree
 246 2012-08-20 01:23:10 <amiller> sipa, did you know that any amount of fanout is logically equivalent to a red black tree
 247 2012-08-20 01:23:21 <amiller> there is no resume to presume you have a set and no tree
 248 2012-08-20 01:23:38 <amiller> there is never a reasonable case when you have a set and no tree
 249 2012-08-20 01:24:04 <sipa> i mean: nothing in my system requires it being implemented as a tree
 250 2012-08-20 01:24:21 <sipa> as soon as you need a merkle root, the structure becomes relevant
 251 2012-08-20 01:24:36 <amiller> right
 252 2012-08-20 01:24:43 <amiller> it's not relevant, but it's not malleable either
 253 2012-08-20 01:24:56 <sipa> and a red-black tree requires a fill rate of 50-100% i suppose in your btree
 254 2012-08-20 01:25:03 <sipa> to be equivalent
 255 2012-08-20 01:25:29 <sipa> anyway, i need sleep
 256 2012-08-20 01:25:34 <jgarzik> meh.  need to implement signature cache in pynode
 257 2012-08-20 01:25:35 <sipa> but it's way too watm
 258 2012-08-20 01:25:39 <sipa> warm
 259 2012-08-20 01:25:46 <jgarzik> otherwise script verf will be too slow, I think
 260 2012-08-20 01:25:56 <jgarzik> or require multi-processing (no threads for pynode)
 261 2012-08-20 01:26:06 <sipa> jgarzik: sigcache only gains you a factor 2 anyway
 262 2012-08-20 01:26:44 <jgarzik> sipa: it also spreads out the load across time, reducing the number of signatures to verf when a block arrives
 263 2012-08-20 01:26:51 Maccer has joined
 264 2012-08-20 01:26:54 <sipa> agree
 265 2012-08-20 01:27:03 <sipa> that's more important probably
 266 2012-08-20 01:27:39 <jgarzik> it makes a big impact, since python is so much slower
 267 2012-08-20 01:27:49 <jgarzik> or rather, I presume it will when it is implemented :)
 268 2012-08-20 01:28:11 user has quit (Ping timeout: 245 seconds)
 269 2012-08-20 01:34:05 RainbowDashh has joined
 270 2012-08-20 01:40:40 RainbowDashh has quit (Ping timeout: 240 seconds)
 271 2012-08-20 01:41:03 user has joined
 272 2012-08-20 01:50:04 Joric has quit ()
 273 2012-08-20 01:52:52 att has quit (Ping timeout: 255 seconds)
 274 2012-08-20 02:01:49 Goilio has joined
 275 2012-08-20 02:02:06 <amiller> http://hackage.haskell.org/package/Monatron this haskell library provides the "zippers as a monad transformers" infrastructure that i want
 276 2012-08-20 02:02:28 <amiller> if i can figure out wtf i'm doing i should be able to port the zipper redblack tree to this structure
 277 2012-08-20 02:02:51 minimoose has quit (Quit: minimoose)
 278 2012-08-20 02:03:24 <sipa> amiller: not sure you mean the same thing with zippers
 279 2012-08-20 02:03:53 Ferroh has quit (Read error: Connection reset by peer)
 280 2012-08-20 02:04:34 <amiller> it lets me abstract out details about how i compute hashes, for example using a cache/memoization table, or for example doing the version without hashes (which would be most comparable to the utxo you have now)
 281 2012-08-20 02:05:53 <sipa> we used it for a code generation monad
 282 2012-08-20 02:06:40 <amiller> that makes sense, it basically provides you with a call stack
 283 2012-08-20 02:06:46 <sipa> where each element in the source language was mapped to a monad transformer in a huge monad stack
 284 2012-08-20 02:07:01 <sipa> and each could have its own state
 285 2012-08-20 02:08:00 <sipa> i don't think you need something that complex here
 286 2012-08-20 02:08:02 hnz_ has quit (Ping timeout: 252 seconds)
 287 2012-08-20 02:08:13 <amiller> it's not complex, it's just the right level of abstraction
 288 2012-08-20 02:08:40 <amiller> the reason why is that i will be able to run it in one mode "without hashes", and then it should be just as efficient as your utxos are right now
 289 2012-08-20 02:09:14 <amiller> and at any point, given my redblack utxo, i can compute the merkleized root hash version of it directly, without needing to be aware of the order histor
 290 2012-08-20 02:09:28 <amiller> and i'd get the same result as if i ran it the entire time "with hashes turned on"
 291 2012-08-20 02:09:47 <sipa> sure, but adding a memoization transformer doesn't require such a monad zipper
 292 2012-08-20 02:10:10 <amiller> i didn't mention memoization yet
 293 2012-08-20 02:10:22 <amiller> but that would be a third monda
 294 2012-08-20 02:10:26 <sipa> right
 295 2012-08-20 02:10:31 <amiller> basically i would have a 'RedBlackTree' monad transformer based on the zipper
 296 2012-08-20 02:10:49 <amiller> and i can insert three different "hash computation" monads to get different tradeoffs
 297 2012-08-20 02:11:07 <sipa> ok
 298 2012-08-20 02:11:43 <amiller> is there an easy way i can ask ultraprune to give me the utxo at a particular block in time
 299 2012-08-20 02:11:48 <amiller> i'd have to simulate a reorg
 300 2012-08-20 02:12:01 <sipa> it only keeps the final state
 301 2012-08-20 02:12:16 <amiller> how do you handle reorgs?
 302 2012-08-20 02:12:36 <sipa> by keeping undo data for blocks
 303 2012-08-20 02:13:14 <amiller> so you create a copy of the database, apply the undo data back to the fork point, then validate the fork?
 304 2012-08-20 02:13:20 <amiller> and if so, you scrap the old database?
 305 2012-08-20 02:13:52 <sipa> there is never a copy
 306 2012-08-20 02:13:53 hnz_ has joined
 307 2012-08-20 02:14:26 <sipa> ah, but the intended changes are kept in a cache in ram until it is certainly correct
 308 2012-08-20 02:14:34 <sipa> and then committed atomiclly
 309 2012-08-20 02:17:26 LightRider has quit (Remote host closed the connection)
 310 2012-08-20 02:17:51 <sipa> which is kind of a copy-on-write duplicate
 311 2012-08-20 02:17:52 <amiller> close enough, modulo the size of your cache
 312 2012-08-20 02:18:56 <sipa> but even at normal IBD time, i use that cache to accumulate the changes.from multiple blocks, to commit there changes in one go to the db
 313 2012-08-20 02:19:01 <Luke-Jr> what do you guys think of PPCoin?
 314 2012-08-20 02:19:29 DiabloD3 has quit (Ping timeout: 244 seconds)
 315 2012-08-20 02:20:49 <sipa> Luke-Jr: what's that?
 316 2012-08-20 02:22:05 <Luke-Jr> sipa: appears to be the first non-scam altcoin
 317 2012-08-20 02:22:12 <Luke-Jr> https://bitcointalk.org/?topic=101820
 318 2012-08-20 02:22:20 <sipa> proof of stake
 319 2012-08-20 02:22:23 <sipa> interesting
 320 2012-08-20 02:23:14 <sipa> anyway, gtg
 321 2012-08-20 02:23:16 <sipa> cya
 322 2012-08-20 02:23:20 <Luke-Jr> they need to change their icon tho. confusing which one is PPCoin and which is Bitcoin XD
 323 2012-08-20 02:23:24 <jgarzik> Luke-Jr: litecoin is a scamcoin?
 324 2012-08-20 02:24:25 Gladamas has quit (Quit: switching computers)
 325 2012-08-20 02:25:50 <Luke-Jr> jgarzik: IMO, yes
 326 2012-08-20 02:28:03 Gladamas has joined
 327 2012-08-20 02:28:03 <sunshinehappy> what about bitcoin?
 328 2012-08-20 02:28:07 <Luke-Jr> jgarzik: their only substantial change is scrypt PoW, which is fundamentally flawed and they knew it from the start
 329 2012-08-20 02:29:03 <smiddi> anybody noticed the sudden raise of Thash/s? http://bitcoincharts.com/bitcoin/   17Th ---> 23Th
 330 2012-08-20 02:30:03 <jgarzik> smiddi: bitcoincharts was "stuck" earlier, maybe that is the result
 331 2012-08-20 02:35:44 <smiddi> jgarzik: look at http://bitcoin.sipa.be/  this is 5Th higher than ever
 332 2012-08-20 02:36:07 <Luke-Jr> BFL testing ASICs?
 333 2012-08-20 02:36:26 <smiddi> ack, think so
 334 2012-08-20 02:38:36 <smiddi> but how many boards must that be  o.O
 335 2012-08-20 02:40:46 <Luke-Jr> 5 rigs?
 336 2012-08-20 02:40:52 <jgarzik> ChainDb: height 194740, block 00000000000000858b066d91a9986f8700b8835b69cde7480487ca64f0039129
 337 2012-08-20 02:40:52 <jgarzik> MemPool: blk.vtx.sz 32, neverseen 32, poolsz 379
 338 2012-08-20 02:41:07 <jgarzik> neverseen 32?  what a bunch of crap.
 339 2012-08-20 02:41:32 <jgarzik> didn't change the pool size on any bitcoind, either
 340 2012-08-20 02:43:01 one_zero has joined
 341 2012-08-20 02:46:27 da2ce7_d is now known as da2ce7
 342 2012-08-20 02:46:32 Cablesaurus has quit (Quit: Easy as 3.14159265358979323846...)
 343 2012-08-20 02:51:05 <gmaxwell> Luke-Jr: sounds like it's another fool centeralized system, the developers can broadcast checkpoints at will.
 344 2012-08-20 02:52:31 <MC-Eeepc> Luke-Jr are you mining ixcoins and iocoins and shit now
 345 2012-08-20 02:52:54 <Luke-Jr> gmaxwell: that can be fixed ;)
 346 2012-08-20 02:54:23 <gmaxwell> right, but it's a sign of cluelessness.
 347 2012-08-20 02:54:48 <gmaxwell> until things like that are fixed the only motivation to touch is is omg-early-adopter.
 348 2012-08-20 02:57:22 <Luke-Jr> gmaxwell: I look at it more from the perspective of, is it likely to scam people
 349 2012-08-20 02:57:33 <Luke-Jr> mere failures can be left to fail
 350 2012-08-20 02:57:48 <gmaxwell> And that incentive is squared by the fact that the subsidy goes down with difficulty instead of up.
 351 2012-08-20 02:58:18 <gmaxwell> e.g. instead of a linear decrease in rewards as its popularity grows, it's a quadratic decrease in rewards.
 352 2012-08-20 02:58:38 <Luke-Jr> same with Bitcoin, just it's got timestamps and block heights tied in
 353 2012-08-20 02:58:41 <gmaxwell> (rewards per computational unit)
 354 2012-08-20 02:58:50 rdponticelli_ has joined
 355 2012-08-20 02:59:13 <Luke-Jr> I don't want to defend it just yet, but it seems to be different from the scamcoins
 356 2012-08-20 02:59:43 rdponticelli has quit (Ping timeout: 260 seconds)
 357 2012-08-20 03:01:27 <doublec> they justify the checkpoint broadcast in their paper
 358 2012-08-20 03:01:41 <doublec> as something they don't like but have 'for now' or something like that iirc
 359 2012-08-20 03:02:28 <doublec> in a post they also said they reserve the right to restart the chain, etc so it seems to be very much an experiment
 360 2012-08-20 03:02:48 <Luke-Jr> doublec: probably true, since at least one person has already threatened to 51% it
 361 2012-08-20 03:03:01 <doublec> Luke-Jr: heh, that didn't take long
 362 2012-08-20 03:03:04 maaku has joined
 363 2012-08-20 03:03:44 <doublec> pity it's not merge minable
 364 2012-08-20 03:03:52 <Luke-Jr> yeah
 365 2012-08-20 03:04:04 <Luke-Jr> fwiw, there's a channel in #ppcoin discussing it
 366 2012-08-20 03:04:08 <doublec> oh thanks
 367 2012-08-20 03:04:59 <doublec> it's the first actually interesting alt coin in a while anyway
 368 2012-08-20 03:05:36 <gmaxwell> doublec: hm? they have a paper? the thread I saw seemed to be saying the design was curently a secret.
 369 2012-08-20 03:05:46 <gmaxwell> link link
 370 2012-08-20 03:06:13 <doublec> gmaxwell: http://www.ppcoin.org/static/ppcoin-paper.pdf
 371 2012-08-20 03:06:50 Anduck has quit (Ping timeout: 245 seconds)
 372 2012-08-20 03:06:58 <gmaxwell> Luke-Jr: looks like there are some non-protocol improvements which we want in bitcoin.
 373 2012-08-20 03:07:21 <Luke-Jr> gmaxwell: oh? I noticed the diff was fairly small..
 374 2012-08-20 03:10:22 <jgarzik> random related:  I always wanted to maintain a parallel tree for "if we could start from scratch" bitcoin improvements.  Nothing pie-in-the-sky...  open up all the script ops, use google protocol buffers rather than a custom serialization, ...
 375 2012-08-20 03:10:37 <jgarzik> i.e. if compatibility was not an issue
 376 2012-08-20 03:12:27 <sunshinehappy> why are there not IRC logs for the weekend??
 377 2012-08-20 03:12:37 <gmaxwell> sad that they're not aware of amiller's txout-set-queries as POW stuff.
 378 2012-08-20 03:13:23 <gmaxwell> Luke-Jr: the payout formula also resulted in a super impressive quasi premine.
 379 2012-08-20 03:13:38 <sunshinehappy> :((((((
 380 2012-08-20 03:13:42 <sunshinehappy> I was relying on those logs
 381 2012-08-20 03:13:44 <doublec> I noticed some people having generation values of 2000+
 382 2012-08-20 03:13:49 roxx has quit (Quit: roxx)
 383 2012-08-20 03:13:55 Siskiyou has joined
 384 2012-08-20 03:17:03 <gmaxwell> doublec: every 16x increase in difficulty halves the subsidy. It's at 387 now and started at 1, the current reward is about 2300. so the block zero should have been ??
 385 2012-08-20 03:17:41 Gladamas has quit (Ping timeout: 240 seconds)
 386 2012-08-20 03:17:49 <gmaxwell> in any case, it's premined all to hell.
 387 2012-08-20 03:17:51 <doublec> gmaxwell: it started at 2xx
 388 2012-08-20 03:17:58 <doublec> gmaxwell: (difficulty that is)
 389 2012-08-20 03:18:44 <gmaxwell> Hm? block1 is difficulty 1.
 390 2012-08-20 03:18:56 <doublec> ok, now I can't find where I read that :)
 391 2012-08-20 03:19:03 <amiller> i bet most unusual difficulty adjustment schemes are provably non-viable
 392 2012-08-20 03:19:44 <doublec> so I am likely wrong
 393 2012-08-20 03:21:04 <Luke-Jr> jgarzik: I've considered that too (and even setup a branch once), but I suspect we have plenty of "we can do it now" improvements to focus on
 394 2012-08-20 03:22:21 Siskiyou has quit (Remote host closed the connection)
 395 2012-08-20 03:22:35 <doublec> gmaxwell: block 1 difficulty is 256
 396 2012-08-20 03:22:39 Siskiyou has joined
 397 2012-08-20 03:22:51 <gmaxwell> er. they appear to base their target off just the last two blocks timestamps (well + the prior difficulty  * alpha) Er. that has to have consequences.
 398 2012-08-20 03:22:52 <doublec> gmaxwell: block 0 is 1.0
 399 2012-08-20 03:23:00 <amiller> "We attempted to design a practical distributed checkpointing protocol but found it difficult to secure against network split attack." lame
 400 2012-08-20 03:24:07 Siskiyou has quit (Remote host closed the connection)
 401 2012-08-20 03:24:35 [7] has quit (Disconnected by services)
 402 2012-08-20 03:24:43 TheSeven has joined
 403 2012-08-20 03:24:48 rdponticelli_ has quit (Ping timeout: 260 seconds)
 404 2012-08-20 03:26:03 <amiller> the energy consumption essential in bitcoin, but the time regularization is... how does randomness work with proof of stake
 405 2012-08-20 03:26:24 <gmaxwell> amiller: see their paper.
 406 2012-08-20 03:29:19 <amiller> unless i'm missing something, you can buy blocks deterministically then, there's no regard to time
 407 2012-08-20 03:29:29 <amiller> if you wanted to fork someone, you could just each take turns out bidding each other
 408 2012-08-20 03:30:15 maaku has quit (Quit: maaku)
 409 2012-08-20 03:32:42 maaku has joined
 410 2012-08-20 03:33:46 _W_ has quit (Excess Flood)
 411 2012-08-20 03:33:53 _W_ has joined
 412 2012-08-20 03:35:04 <gmaxwell> What incentive exists in this system to include transactions?
 413 2012-08-20 03:36:46 maaku has quit (Client Quit)
 414 2012-08-20 03:37:35 <gmaxwell> oh duh, because they're picking the longest chain based on how many transactions it includes.
 415 2012-08-20 03:38:05 wizkid057 has quit (Read error: Connection reset by peer)
 416 2012-08-20 03:38:25 <amiller> there's a contradiction between two components of the proposal, since the 51% measurement is not about the actual amount of bitcoins you have, but the number of old coins you have
 417 2012-08-20 03:38:41 <amiller> so a 10% attacker who holds onto his coins forever will have the advantage over 90% of people who spend their coins
 418 2012-08-20 03:39:02 <gmaxwell> indeed.
 419 2012-08-20 03:40:14 <gmaxwell> so without their centerally controlled checkpoints you could do a really awesome timewarpish attack on this puppy.
 420 2012-08-20 03:41:06 <gmaxwell> You'd fork the chain far back, and then fudge your timestamps so that you mine a ton of coins— more than the real chain has. Then you paddle those puppies back and forth, thus making yourself a strongly prefered chain.
 421 2012-08-20 03:41:10 <gmaxwell> Bummer.
 422 2012-08-20 03:41:46 maaku has joined
 423 2012-08-20 03:41:53 <amiller> "form of proof of ownership of the currency." what does ownership of the currency have to do with "coin age"
 424 2012-08-20 03:43:17 <gmaxwell> yea, thats muddled. Proof of stake as discussed is about coin days destroyed. Not about having lots of coins, because without 'been sitting still not moving' factor the dude with the most coins always wins.
 425 2012-08-20 03:44:19 <amiller> so if they really mean that making a  <49%  of total coin-age assumption belongs to attackers, what does that mean
 426 2012-08-20 03:44:39 <amiller> i think that assumption roughly means "most coins held by honest people haven't being spent recently"
 427 2012-08-20 03:44:51 <amiller> haven't been*
 428 2012-08-20 03:45:09 pickett_ has joined
 429 2012-08-20 03:45:29 <amiller> whenever you make a transaction, you're consuming stake
 430 2012-08-20 03:46:05 maaku has quit (Ping timeout: 246 seconds)
 431 2012-08-20 03:46:07 <amiller> so there's absolutely no size of attacker that this defeats, if "making transactions" is something that honest people do in the normal use
 432 2012-08-20 03:48:10 AlexWaters has joined
 433 2012-08-20 03:48:56 wizkid057 has joined
 434 2012-08-20 03:49:18 pickett has quit (Ping timeout: 276 seconds)
 435 2012-08-20 03:49:53 RainbowDashh has joined
 436 2012-08-20 03:49:54 RainbowDashh has quit (Changing host)
 437 2012-08-20 03:49:54 RainbowDashh has joined
 438 2012-08-20 03:50:27 <amiller> "First the cost of controlling significant stake might be higher than the cost of acquiring significant mining power," well no there's no reason to think that, especially because "stake" isn't proportional to coins
 439 2012-08-20 03:52:08 <gmaxwell> amiller: yea, one argument that I eventually got is that all fungible resources are equal.
 440 2012-08-20 03:52:58 <gmaxwell> in terms of representing an acquistion cost; the best idea I've seen once observed with that lens is at least making sure the resource reflects a capacity to do useful work for the network.
 441 2012-08-20 03:53:08 RainbowDashh has quit (Client Quit)
 442 2012-08-20 03:53:51 AlexWaters has quit (Remote host closed the connection)
 443 2012-08-20 03:56:31 RainbowDashh has joined
 444 2012-08-20 03:56:36 RainbowDashh has quit (Changing host)
 445 2012-08-20 03:56:36 RainbowDashh has joined
 446 2012-08-20 03:58:48 roxx has joined
 447 2012-08-20 04:00:45 Ferroh has joined
 448 2012-08-20 04:01:40 Gladamas has joined
 449 2012-08-20 04:01:50 RainbowDashh has quit (Ping timeout: 246 seconds)
 450 2012-08-20 04:04:44 <amiller> it pretty easy for people to exchange trade bitcoins/ppcoins without actually making an official transaction, for example with casacius coins
 451 2012-08-20 04:05:11 <amiller> of course, it would be lame if that was the _only_ way to exchange coins, because it's not very secure and reducing reliance is the point of the protocol
 452 2012-08-20 04:05:37 <amiller> but since it's certainly possible, it would be bad if the protocol were vulnerable to that kind of transaction
 453 2012-08-20 04:06:52 <amiller> so basically it's 51% successful in the case that everyone trusts each other and exchanges coins without making transactions
 454 2012-08-20 04:07:00 <amiller> but the minute you make a transaction, you destroy your advatange over the attacker
 455 2012-08-20 04:12:40 <gmaxwell> people mining up the difficulty seems to be the only thing preventing unbounded inflation, which seems.. weird to me.
 456 2012-08-20 04:14:33 Cablesaurus has joined
 457 2012-08-20 04:16:32 <gmaxwell> Luke-Jr: since you were porting fixes against it, would you happen to have an idea of whatever improvements it has that we should pull into bitcoin?
 458 2012-08-20 04:16:50 <gmaxwell> (I mean, non protocol stuff, of course)
 459 2012-08-20 04:17:04 <Luke-Jr> gmaxwell: dunno, it was REALLY trivial
 460 2012-08-20 04:17:15 <Luke-Jr> I just did git merge 0.6.x, resolved some minor conflicts
 461 2012-08-20 04:18:06 <Luke-Jr> when done with that:  40 files changed, 2525 insertions(+), 620 deletions(-)
 462 2012-08-20 04:18:26 <Luke-Jr> they bump win32 dep versions for gitian
 463 2012-08-20 04:19:45 <gmaxwell> I see getinfo gains
 464 2012-08-20 04:19:45 <gmaxwell>     obj.push_back(Pair("ip",            addrSeenByPeer.ToStringIP()));
 465 2012-08-20 04:19:57 <gmaxwell> which sounds useful (though it's v4 only centric)
 466 2012-08-20 04:21:39 <Luke-Jr> src/util.h:        return (pthread_t)0; <-- this is in our code, and invalid O.o
 467 2012-08-20 04:24:03 brwyatt is now known as brwyatt|Away
 468 2012-08-20 04:28:54 <BCBot>  Stats: http://bit.ly/bitcoin-irc-stats
 469 2012-08-20 04:29:08 rofer has quit (Ping timeout: 246 seconds)
 470 2012-08-20 04:29:20 drazak has quit (Ping timeout: 252 seconds)
 471 2012-08-20 04:29:53 [\\\] has joined
 472 2012-08-20 04:31:41 Gladamas_ has joined
 473 2012-08-20 04:31:43 imsaguy has quit (Ping timeout: 265 seconds)
 474 2012-08-20 04:33:11 Gladamas has quit (Ping timeout: 240 seconds)
 475 2012-08-20 04:35:33 Gladamas_ is now known as Gladamas
 476 2012-08-20 04:36:27 Gladamas has quit (Client Quit)
 477 2012-08-20 04:37:56 rofer has joined
 478 2012-08-20 04:38:48 drazak has joined
 479 2012-08-20 04:40:44 user has quit (Quit: Leaving)
 480 2012-08-20 04:40:50 Gladamas has joined
 481 2012-08-20 04:47:01 Karmaon1 has joined
 482 2012-08-20 04:48:02 da2ce772 has joined
 483 2012-08-20 04:59:13 [\\\] is now known as imsaguy
 484 2012-08-20 04:59:45 imsaguy is now known as [\\\]
 485 2012-08-20 04:59:57 old-timer has joined
 486 2012-08-20 05:00:29 <old-timer> What is the default CPU miner?
 487 2012-08-20 05:00:38 <old-timer> Or rather where is it?
 488 2012-08-20 05:01:01 <old-timer> Is it completely stripped out of bitcoin?
 489 2012-08-20 05:01:24 <old-timer> I've enabled it in bitcoind but CPU is doing nothing.
 490 2012-08-20 05:01:52 MC-Eeepc has quit (Ping timeout: 272 seconds)
 491 2012-08-20 05:01:55 <old-timer> I can't believe you removed it from the default client.
 492 2012-08-20 05:02:18 <old-timer> When was it removed from the GUI?
 493 2012-08-20 05:02:46 <old-timer> Anyone?
 494 2012-08-20 05:04:43 da2ce772 has quit (Ping timeout: 276 seconds)
 495 2012-08-20 05:05:14 <forrestv> old-timer, it was removed a while ago
 496 2012-08-20 05:05:18 ThomasV_ has joined
 497 2012-08-20 05:06:08 <old-timer> Was it removed from the default bitcoind?
 498 2012-08-20 05:06:16 <forrestv> i thought so... checking now
 499 2012-08-20 05:07:12 da2ce772 has joined
 500 2012-08-20 05:08:13 <forrestv> old-timer, ah, no, it still appears to be in there, at least in my week-old version built from git
 501 2012-08-20 05:08:22 <forrestv> there was talk about removing it a while, though
 502 2012-08-20 05:08:37 <forrestv> a while ago
 503 2012-08-20 05:16:34 RazielZ has joined
 504 2012-08-20 05:17:46 <gmaxwell> forrestv: we hid it from the gui, but its still there.
 505 2012-08-20 05:18:34 <gmaxwell> And it's hidden from the gui because we got tired of people showing up on IRC _furious_ that they'd "mined for weeks and got nothing".
 506 2012-08-20 05:19:20 <forrestv> mmhm. well now we have people furious that they can't use the inefficient builtin cpu miner, apparently
 507 2012-08-20 05:19:23 <gmaxwell> old-timer: and if it's enabled doing but nothing its because you're either not current with the chain or you don't have connections, it won't and has never worked in those cases.
 508 2012-08-20 05:19:39 <gmaxwell> And it was removed something like a year ago.
 509 2012-08-20 05:20:46 <old-timer> If I have changed the bitcoin payout split for testing services, how would I get it to start mining?
 510 2012-08-20 05:21:17 <gmaxwell> old-timer: use testnet.
 511 2012-08-20 05:21:40 <old-timer> I don't want to use testnet.
 512 2012-08-20 05:22:17 <gmaxwell> And, to finish the argument— At the current difficulty at 12 MH (a _fast_ cpu with a state of the art cpu miner, not the one in bitcoind) has an expected time to mine a block of 24 years.
 513 2012-08-20 05:22:38 <gmaxwell> old-timer: so if you're planning on cpu mining on the bitcoin network, I hope you're feeling pretty patient.
 514 2012-08-20 05:22:42 <old-timer> And if the difficulty dropped to 1?
 515 2012-08-20 05:22:47 <Luke-Jr> gmaxwell: erm, I get 15 MH/s with a mid-level CPU :p
 516 2012-08-20 05:22:51 ovidiusoft has joined
 517 2012-08-20 05:22:51 <old-timer> Then it would again be relevant.
 518 2012-08-20 05:23:13 <Luke-Jr> ;;bc,calc 12000000
 519 2012-08-20 05:23:14 <gribble> The average time to generate a block at 12000000 Khps, given current difficulty of 2190865.9701029 , is 1 week, 2 days, 1 hour, 49 minutes, and 1 second
 520 2012-08-20 05:23:18 <Luke-Jr> ;;bc,calc 12000
 521 2012-08-20 05:23:19 <gribble> The average time to generate a block at 12000 Khps, given current difficulty of 2190865.9701029 , is 24 years, 45 weeks, 0 days, 17 hours, 4 minutes, and 34 seconds
 522 2012-08-20 05:23:32 <Luke-Jr> hmm, I'd think it'd take longer
 523 2012-08-20 05:23:35 <gmaxwell> old-timer: It's not going to do that— ever, considering that just a couple cheap gpus can keep it way above that. But regardless, if it did that, then someone could reasonably add the option back to the gui.
 524 2012-08-20 05:24:24 <old-timer> Does the client need to be connected to another client at the same block count in order to mine?
 525 2012-08-20 05:24:27 <midnightmagic> gmaxwell: I can do 22MH/s with a 6-core 1090T, and that's not, IMO, even really fully optimized.
 526 2012-08-20 05:24:43 <Luke-Jr> gmaxwell: meh, not really. kitchen sinks aren't a good idea
 527 2012-08-20 05:24:49 <midnightmagic> That CPU is pretty old and busted, too. I'm disappointed with how poorly it's held up over the years.
 528 2012-08-20 05:25:37 <gmaxwell> midnightmagic: really? I don't think I ever saw hashrates anywher near that high out of a 1055T
 529 2012-08-20 05:26:00 <gmaxwell> In any case, 12years, 24 years, it's still unlikely to find a block in reasonable time.
 530 2012-08-20 05:26:29 <gmaxwell> old-timer: What exactly are you trying to accomplish?
 531 2012-08-20 05:26:47 <midnightmagic> it was a derived measurement, but as far as I could tell, about 22MH using a dedicated CPU miner. I remember being surprised at how much stronger it was than my..  I think it was a 9600GT.
 532 2012-08-20 05:27:02 enquirer has quit (Ping timeout: 244 seconds)
 533 2012-08-20 05:29:00 <old-timer> I want to diverge at an earlier bock by lowering the subsidy.
 534 2012-08-20 05:29:49 <midnightmagic> yeah, and that's with a static difficulty. out at those times, the long-term difficulty increases end up actually making a difference. I'd be willing to bet (entirely without working out at all) that he'd never see a block, ever.
 535 2012-08-20 05:30:35 <midnightmagic> old-timer: Are you working on some kind of parallel altchain?
 536 2012-08-20 05:30:38 <old-timer> If I diverge from the block count when the difficulty was still one, then I should be able to generate just fine.
 537 2012-08-20 05:30:44 <gmaxwell> old-timer: okay, well, you need two nodes connected, and it need to believe its not in the initial block download.
 538 2012-08-20 05:30:49 <Luke-Jr> old-timer: use testnet. that's what it's for
 539 2012-08-20 05:30:51 <old-timer> Sort of.
 540 2012-08-20 05:31:23 <gmaxwell> Luke-Jr: hes going to be off on a fork regardless.
 541 2012-08-20 05:31:27 <old-timer> Yes, I know that's what testnet is for.
 542 2012-08-20 05:31:33 <doublec> I do the same as old-timer for my testing :)
 543 2012-08-20 05:31:43 <doublec> start two nodes, disconnected from the network starting at block 1
 544 2012-08-20 05:32:01 <midnightmagic> old-timer:  Well..  there're also the checkpoints to consider too. You'll have to disable the checkpoint logic.
 545 2012-08-20 05:32:13 <gmaxwell> old-timer: In any case; two nodes, and remove the IsInitialBlockDownload test in bitcoinrpc. and/or nuke all the checkpoints.
 546 2012-08-20 05:32:22 <doublec> yeah, checkpoints and that global for estimated block count or whatever it's called
 547 2012-08-20 05:32:28 <old-timer> I don't want block 1. Oh, and by the way, how do I start bitcoind without outgoing connections?
 548 2012-08-20 05:32:43 <gmaxwell> -connect=127.0.0.1 works fine.
 549 2012-08-20 05:33:07 <old-timer> -connect=127.0.0.1 doesn't work.
 550 2012-08-20 05:33:18 <midnightmagic>  -noirc -nodnsseed I *think* will remove all bootstrap peer location stuff?
 551 2012-08-20 05:33:40 <gmaxwell> old-timer: Please be more clear about what you mean by "doesn't work".
 552 2012-08-20 05:33:51 <gmaxwell> midnightmagic: noirc is default.
 553 2012-08-20 05:33:56 <gmaxwell> (for bitcoin)
 554 2012-08-20 05:34:22 <midnightmagic> gmaxwell: Is it now?  Ah, that's a good thing. Hey, do I have to write my own seeder if I want to run a dns seeder?  Seems like everyone's running their own.
 555 2012-08-20 05:34:43 <midnightmagic> ah who am I kidding, I'll never get around to that. please ignore that question.
 556 2012-08-20 05:34:46 <gmaxwell> midnightmagic: diversity is good. :) Though bluematt's and sipa's are available.
 557 2012-08-20 05:34:47 <midnightmagic> old-timer: What are you up to?
 558 2012-08-20 05:34:55 <old-timer> Never mind, it must have been another option that I had
 559 2012-08-20 05:35:19 * Luke-Jr wonders if he should try BlueMatt's
 560 2012-08-20 05:40:37 * midnightmagic prods old-timer.
 561 2012-08-20 05:41:09 <old-timer> Ok, thanks for your help.
 562 2012-08-20 05:41:09 * midnightmagic pulls out a fork
 563 2012-08-20 05:41:30 <old-timer> I've got my clients connected. Now I think I just need to get rid of some checkpoints.
 564 2012-08-20 05:41:51 <midnightmagic> old-timer: Whatchya doon?
 565 2012-08-20 05:42:19 <old-timer> midnightmagic, top secret-ish
 566 2012-08-20 05:43:11 <midnightmagic> old-timer: So when do we get paid for the private support? Is this a project which we are all going to celebrate when we find out about it?
 567 2012-08-20 05:43:18 RazielZ has quit (Read error: Connection reset by peer)
 568 2012-08-20 05:43:34 RazielZ has joined
 569 2012-08-20 05:44:47 tonikt has joined
 570 2012-08-20 05:45:52 <midnightmagic> meh..
 571 2012-08-20 05:46:09 <old-timer> Celebrate? I doubt it. But probably won't be upset or anything.
 572 2012-08-20 05:47:17 AlexWaters has joined
 573 2012-08-20 05:48:21 RazielZ has quit (Read error: Connection reset by peer)
 574 2012-08-20 05:48:36 RazielZ has joined
 575 2012-08-20 05:51:07 RazielZ has quit (Read error: Connection reset by peer)
 576 2012-08-20 05:51:26 RazielZ has joined
 577 2012-08-20 05:54:22 <gmaxwell> old-timer: So are you investigating a bug, starting up another altcoin of questionable merit, troubleshooting non-bitcoin code, or what?
 578 2012-08-20 05:55:29 <gmaxwell> Or are you another one of those crazy people who think they can stop the subsidy halving by just getting miners to switch?
 579 2012-08-20 05:57:37 <old-timer> I'm just an old-timer who is pissed that you took out the CPU timer from the GUI. Thank you for your help. Now get off my lawn.
 580 2012-08-20 05:58:22 <gmaxwell> old-timer: I'll commit a change right now putting it back in, if you promise to personally handle every angry email, and explain to people why their computer has been heating their house for months without a bitcent in return.
 581 2012-08-20 05:58:35 <Luke-Jr> old-timer: your lawn?
 582 2012-08-20 05:58:56 B0g4r7__ has joined
 583 2012-08-20 05:59:17 <old-timer> How about a documented way to re-enable it?
 584 2012-08-20 05:59:43 <old-timer> Like a command line switch or something.
 585 2012-08-20 05:59:49 <Luke-Jr> it's completely useless. why bother?
 586 2012-08-20 05:59:55 <Luke-Jr> (also, it IS documented already)
 587 2012-08-20 05:59:56 <gmaxwell> old-timer: er, it's documented in the commandline help.
 588 2012-08-20 06:00:41 <gmaxwell>   -gen                   Generate coins
 589 2012-08-20 06:00:55 <gmaxwell> It's also documented in the wiki page for the config file.
 590 2012-08-20 06:01:09 <Luke-Jr> gmaxwell: maybe that should be changed to "Waste CPU"
 591 2012-08-20 06:01:14 <gmaxwell> hah.
 592 2012-08-20 06:01:21 <old-timer> I want it in the GUI. Look, I understand why you took it out. Now, lets supposed there was a controled ruduction of CPU mining. The difficulting could be reduced in a few months, not years.
 593 2012-08-20 06:01:54 <old-timer> It's a safety measure to the network.
 594 2012-08-20 06:01:58 <Luke-Jr> old-timer: but that's not good for Bitcoin, so it won't happen
 595 2012-08-20 06:02:16 <Luke-Jr> and miners should be miners, and wallets should be wallets
 596 2012-08-20 06:02:18 <gmaxwell> ssh.
 597 2012-08-20 06:02:21 <Luke-Jr> there is no reason to mix them
 598 2012-08-20 06:02:34 B0g4r7 has quit (Ping timeout: 276 seconds)
 599 2012-08-20 06:02:34 B0g4r7__ is now known as B0g4r7
 600 2012-08-20 06:02:58 <old-timer> If there wasn't a reason to mix them, then it wouldn't have been in the original client.
 601 2012-08-20 06:03:07 <Luke-Jr> you give Satoshi too much credit
 602 2012-08-20 06:03:50 <gmaxwell> old-timer: If people are going to the trouble of twiddling a gui option, then is a config option or commandline switch that much of an additional barrier?
 603 2012-08-20 06:04:11 <old-timer> I would apprieciate it if it could be re-enabled within the GUI. Was it taken out before or after the Qt switch?
 604 2012-08-20 06:04:43 <Luke-Jr> old-timer: forget it already
 605 2012-08-20 06:04:52 <gmaxwell> Luke-Jr: hush.
 606 2012-08-20 06:04:55 <old-timer> Does anyone happen to have a revision number when it was removed?
 607 2012-08-20 06:05:03 <gmaxwell> old-timer: IIRC it was before but I'm trying to find it now.
 608 2012-08-20 06:05:04 enquirer has joined
 609 2012-08-20 06:05:26 <old-timer> Thank you.
 610 2012-08-20 06:05:33 <Luke-Jr> e93e5349cb32e47bf68f9cc682cb84642a02cfef
 611 2012-08-20 06:05:45 <Luke-Jr> aka jgarzik/remove-gui-gen and pull #142
 612 2012-08-20 06:07:02 <Luke-Jr> and SSE4 optimizations were removed in b26141e2c5836ccd20bd32a9c653cf2ba5e5b5ee (#141, jgarzik/remove-4way)
 613 2012-08-20 06:07:10 <Luke-Jr> err, SSE2
 614 2012-08-20 06:07:52 <midnightmagic> old-timer: Satoshi did a lot of what he did because it was just him and a couple other people writing it. Sometimes coding efficiently requires you to take shortcuts if you want to get done quickly. So even if Satoshi *did* it that way, that doesn't imply he *thought it was the best way to do it.*
 615 2012-08-20 06:08:30 <gmaxwell> In any case, it would be much more interesting to reintroduce integrated mining in combination with distributed subsidy sharing support.
 616 2012-08-20 06:08:44 <midnightmagic> a.k.a. p2pool in mainline!
 617 2012-08-20 06:08:46 * midnightmagic cheers.
 618 2012-08-20 06:08:58 <old-timer> Look, I appreciate everyone's contributions, it just put me in a bad mood coming home and not recognizing the place.
 619 2012-08-20 06:09:07 <Luke-Jr> midnightmagic: no :p
 620 2012-08-20 06:09:26 <midnightmagic> Luke-Jr: Why not?
 621 2012-08-20 06:09:32 <Luke-Jr> midnightmagic: because it's biased toward a pool
 622 2012-08-20 06:09:34 <Luke-Jr> duh
 623 2012-08-20 06:10:03 roconnor has quit (Ping timeout: 252 seconds)
 624 2012-08-20 06:10:05 roconnor_ has joined
 625 2012-08-20 06:10:18 <gmaxwell> Hey, it would only take 10,000 22MH/s (really fast cpus) miners at current difficulty 1008 days to mine 2016 blocks to quarter the difficulty. hurrah.
 626 2012-08-20 06:10:34 ThomasV_ has quit (Quit: Quitte)
 627 2012-08-20 06:10:35 <midnightmagic> Luke-Jr: I preferred you when you weren't capitalized
 628 2012-08-20 06:11:10 Guest63372 is now known as bdcs
 629 2012-08-20 06:11:35 <midnightmagic> old-timer: So where did you go and when did you leave?
 630 2012-08-20 06:12:09 <old-timer> Just offline.
 631 2012-08-20 06:12:44 <Luke-Jr> old-timer: you know, if you liked wxBitcoin, I wouldn't mind helping you get off the ground reviving it …
 632 2012-08-20 06:12:54 <Luke-Jr> old-timer: then you could, as maintainer, add the menu item back..
 633 2012-08-20 06:14:35 <gmaxwell> Unfortunately the rise of mining as a clearly net-profitable adventure has made people astonishingly disdainful of mining at a loss.
 634 2012-08-20 06:14:39 <midnightmagic> Or you could take the opportunity to strip all the important guts out of the GUI entirely and make it a separate piece of software where it doesn't matter if it breaks or doesn't get linked against a multithreaded library!
 635 2012-08-20 06:14:44 <gmaxwell> (a loss over electrical costs, I mean)
 636 2012-08-20 06:14:50 <old-timer> Thanks for the offer. But I'm sure I'll get used to the new client eventually.
 637 2012-08-20 06:17:35 Marf has joined
 638 2012-08-20 06:20:04 talso has quit (Ping timeout: 245 seconds)
 639 2012-08-20 06:23:47 <old-timer> Ok, I've got mining working. I promise to not harm the network. See ya all later. Keep up the great work.
 640 2012-08-20 06:24:19 old-timer has left ()
 641 2012-08-20 06:24:39 finway has joined
 642 2012-08-20 06:24:45 <finway> hello
 643 2012-08-20 06:27:30 talso has joined
 644 2012-08-20 06:32:35 Obsi has quit (Read error: Connection reset by peer)
 645 2012-08-20 06:34:17 <finway> Why there's no log on 16 17 18 ?
 646 2012-08-20 06:35:11 <finway> Did some one clear it out or just nobody talks ?
 647 2012-08-20 06:35:28 <gmaxwell> Censored, to hide the information about the upcoming Secret Event.
 648 2012-08-20 06:35:38 <sunshinehappy> seriously? I needed those logs
 649 2012-08-20 06:37:57 <gmaxwell> No. I'm kidding, the logging service is unreliable. It's gone down twice recently.
 650 2012-08-20 06:38:12 <sunshinehappy> oh lol
 651 2012-08-20 06:38:35 <sunshinehappy> someone gave me a good command line script but I cleared my .bash_profilebecause it had passwords in it so I lost it
 652 2012-08-20 06:38:42 <sunshinehappy> but I was actually able to remember it
 653 2012-08-20 06:38:54 <sunshinehappy> but I was trying to find it in the log :/
 654 2012-08-20 06:39:07 <gmaxwell> sunshinehappy: to avoid that problem in the future, https://bitcointalk.org/index.php?topic=54671.0
 655 2012-08-20 06:39:18 CodesInChaos has joined
 656 2012-08-20 06:39:40 bdcs is now known as Guest15691
 657 2012-08-20 06:39:55 john__ has joined
 658 2012-08-20 06:40:34 <sunshinehappy> neat! thanks
 659 2012-08-20 06:40:54 RainbowDashh has joined
 660 2012-08-20 06:42:30 Obsi has joined
 661 2012-08-20 06:45:45 john__ has quit (Quit: Leaving)
 662 2012-08-20 06:45:50 phantomcircuit_ has joined
 663 2012-08-20 06:45:57 <finway> What's purecoin, i just noticed that rocornor  return with it.
 664 2012-08-20 06:46:14 phantomcircuit has quit (Disconnected by services)
 665 2012-08-20 06:46:18 phantomcircuit_ is now known as phantomcircuit
 666 2012-08-20 06:46:20 <gmaxwell> finway: an incomplete bitcoin implementation.
 667 2012-08-20 06:46:45 phantomcircuit_ has joined
 668 2012-08-20 06:46:45 <finway> gmaxwell, i think he means  imcompatible ?
 669 2012-08-20 06:47:34 <finway> gmaxwell, where can i find the code or paper ?
 670 2012-08-20 06:47:45 <Luke-Jr> [06:29:54] <gmaxwell> Censored, to hide the information about the upcoming Secret Event. <-- lol
 671 2012-08-20 06:50:06 Gladamas has quit (Remote host closed the connection)
 672 2012-08-20 06:53:01 finway has quit (Quit: Page closed)
 673 2012-08-20 06:59:08 sunshinehappy has quit (Quit: Leaving)
 674 2012-08-20 06:59:45 Maccer has quit (Ping timeout: 245 seconds)
 675 2012-08-20 07:05:48 AlexWaters has quit (Quit: Leaving.)
 676 2012-08-20 07:06:31 vigilyn has quit (Read error: Connection reset by peer)
 677 2012-08-20 07:06:53 Fnar has quit (Ping timeout: 252 seconds)
 678 2012-08-20 07:08:44 <amiller> http://www.rsa.com/rsalabs/staff/bios/aoprea/publications/time-stamping.pdf interesting article by rsalabs of all things, on the use of merkle tries and merkle binary trees for some secure storage protocols
 679 2012-08-20 07:08:59 <amiller> they have comparisons of efficiency, for worst case, and for average cases with random data
 680 2012-08-20 07:09:39 <amiller> but here's the thing, the only way they got merkle _tries_ to work correctly is that they had an _append only_ structure
 681 2012-08-20 07:11:01 asa has quit (Remote host closed the connection)
 682 2012-08-20 07:11:31 asa has joined
 683 2012-08-20 07:14:09 <amiller> you know how i keep talking about a skip graph built over the blockchain itself, that's the sort of thing that you really want a patricia trie for
 684 2012-08-20 07:15:06 <amiller> it just grows forever, until you forget about it basically
 685 2012-08-20 07:18:13 hnz_ has quit ()
 686 2012-08-20 07:18:35 <amiller> but the UTXO is different, it needs to be a balanced tree because we treat it differently
 687 2012-08-20 07:19:00 roxx has quit (Quit: roxx)
 688 2012-08-20 07:20:26 <amiller> tries are protected by proof of work, but balanced trees are deterministically tough.
 689 2012-08-20 07:22:50 <amiller> clients produce transactions - their hashes are unconstrained so you can't give preference to them, but fortunately they only need to be validated within a smaller set (not necessarily an infinitely growing one)
 690 2012-08-20 07:23:20 <amiller> maybe that's a good place to draw the line - do you guys think of the UTXO set as something that grows forever, or something that stabilizes to a finite size?
 691 2012-08-20 07:27:30 vampireb has quit (Quit: Lost terminal)
 692 2012-08-20 07:30:30 osxorgate has joined
 693 2012-08-20 07:30:39 cande has joined
 694 2012-08-20 07:30:58 tonikt has quit (Ping timeout: 276 seconds)
 695 2012-08-20 07:34:02 <amiller> there are presumably more unique requests for transaction validation so you can't share that load as easily
 696 2012-08-20 07:34:26 <amiller> on the other hand proof-of-work chains are relevant to everyone, so they will propagate easily through the network
 697 2012-08-20 07:35:30 bitcoiner has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
 698 2012-08-20 07:38:49 da2ce772 has quit (Ping timeout: 244 seconds)
 699 2012-08-20 07:41:52 tonikt has joined
 700 2012-08-20 07:45:53 cande has quit (Quit: Lämnar)
 701 2012-08-20 07:49:10 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Ping timeout: 276 seconds)
 702 2012-08-20 07:52:40 Cablesaurus has quit (Quit: Clap on! , Clap off! Clap@#&$NO CARRIER)
 703 2012-08-20 07:55:55 Maccer has joined
 704 2012-08-20 07:56:02 <amiller> UTXO belongs to the clients, hash-value-highway belongs to the miners
 705 2012-08-20 08:02:23 Cablesaurus has joined
 706 2012-08-20 08:03:54 tower has quit (Ping timeout: 265 seconds)
 707 2012-08-20 08:12:02 denisx has joined
 708 2012-08-20 08:18:20 tower has joined
 709 2012-08-20 08:18:44 <amiller> miners will compete by storing chunks of historic UTXO data, in a sharded way, which will allow us to validate long forks by swarm effort
 710 2012-08-20 08:18:58 <amiller> their average case is mining, their worst-case is dealing with a fork
 711 2012-08-20 08:19:44 <amiller> on the other side, there are clients, who hire miners and validate novel blocks and novel transactions
 712 2012-08-20 08:22:25 <amiller> they need to make random accesses to the current UTXO.
 713 2012-08-20 08:22:58 tower has quit (Ping timeout: 248 seconds)
 714 2012-08-20 08:25:02 Clipse has quit (Quit: Clipse)
 715 2012-08-20 08:27:08 Cablesaurus has quit (Changing host)
 716 2012-08-20 08:27:08 Cablesaurus has joined
 717 2012-08-20 08:28:24 Clipse has joined
 718 2012-08-20 08:28:48 <dust-otc> can someone explain how miners are rewarded with ppcoin's proof of stake?
 719 2012-08-20 08:29:13 <dust-otc> can transaction fees be collected just by holding old coins?
 720 2012-08-20 08:29:26 darkee has joined
 721 2012-08-20 08:33:32 Karmaon1 has quit (Remote host closed the connection)
 722 2012-08-20 08:34:31 CShBot has joined
 723 2012-08-20 08:35:45 Maccer has quit (Excess Flood)
 724 2012-08-20 08:37:13 CShBot has quit (Quit: SocketException)
 725 2012-08-20 08:37:17 AlexWaters has joined
 726 2012-08-20 08:37:17 AlexWaters has quit (Client Quit)
 727 2012-08-20 08:37:52 AlexWaters has joined
 728 2012-08-20 08:40:17 RainbowDashh is now known as Rabbit67890
 729 2012-08-20 08:42:17 AlexWaters has quit (Client Quit)
 730 2012-08-20 08:43:12 AlexWaters has joined
 731 2012-08-20 08:43:51 Zarutian has joined
 732 2012-08-20 08:44:09 AlexWaters has quit (Client Quit)
 733 2012-08-20 08:47:13 Rabbit67890 has quit (Quit: Computer has gone to sleep.)
 734 2012-08-20 08:49:59 Maccer has joined
 735 2012-08-20 08:49:59 t7 has joined
 736 2012-08-20 08:51:17 Anduck has joined
 737 2012-08-20 09:00:01 guruvan has quit (Ping timeout: 276 seconds)
 738 2012-08-20 09:00:02 guruvan_ is now known as guruvan
 739 2012-08-20 09:04:00 AlexWaters has joined
 740 2012-08-20 09:04:00 AlexWaters has quit (Client Quit)
 741 2012-08-20 09:05:57 PhantomSpark has joined
 742 2012-08-20 09:08:49 guruvan- has joined
 743 2012-08-20 09:13:22 tower has joined
 744 2012-08-20 09:18:29 danbri has joined
 745 2012-08-20 09:20:33 AlexWaters has joined
 746 2012-08-20 09:30:49 phantomcircuit has quit (Read error: Connection reset by peer)
 747 2012-08-20 09:32:54 olp has quit (Ping timeout: 246 seconds)
 748 2012-08-20 09:35:47 danbri has quit (Remote host closed the connection)
 749 2012-08-20 09:36:37 Zarutian has quit (Quit: Zarutian)
 750 2012-08-20 09:38:03 olp has joined
 751 2012-08-20 09:38:53 sacarlson has joined
 752 2012-08-20 09:41:15 <sacarlson> I've been away for some time and had to install a new version of bitcoin on ubuntu 0.3.24 from ppa,  only real question is what block are we at now?  I've been downloading all day so far and got 126241 blocks so far,  how far I got to go?
 753 2012-08-20 09:42:38 <[Tycho]> ;;bc.last
 754 2012-08-20 09:42:39 <gribble> Error: "bc.last" is not a valid command.
 755 2012-08-20 09:42:42 <[Tycho]> ;;bc,last
 756 2012-08-20 09:42:42 <gribble> Error: "bc,last" is not a valid command.
 757 2012-08-20 09:42:47 <[Tycho]> ;;bc.help
 758 2012-08-20 09:42:47 <gribble> Error: "bc.help" is not a valid command.
 759 2012-08-20 09:43:00 genjix is now known as genjix_afk
 760 2012-08-20 09:43:14 <[Tycho]> ;;bc,help
 761 2012-08-20 09:43:14 <gribble> Alias bc,24hprc, Alias bc,avgprc, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btcguild, Alias bc,calc, Alias bc,calcd, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias bc,fx, Alias bc,gen, Alias bc,gend, Alias bc,halfreward, Alias bc,help, Alias bc,hextarget, Alias bc,intersango, Alias (2 more messages)
 762 2012-08-20 09:43:22 <[Tycho]> ;;bc,blocks
 763 2012-08-20 09:43:23 <gribble> 194785
 764 2012-08-20 09:44:06 <[Tycho]> Wow, 200k coming soon.
 765 2012-08-20 09:44:13 <[Tycho]> ;;bc,halfreward
 766 2012-08-20 09:44:14 <gribble> Estimated time of bitcoin block reward halving: Mon Dec  3 17:28:00 2012 | Time remaining: 15 weeks, 0 days, 15 hours, 50 minutes, and 0 seconds
 767 2012-08-20 09:44:35 <[Tycho]> ;;bc,estimate
 768 2012-08-20 09:44:36 <gribble> 2408120.51951692
 769 2012-08-20 09:45:16 paraipan has quit (Remote host closed the connection)
 770 2012-08-20 09:46:04 paraipan has joined
 771 2012-08-20 09:46:52 <ersi> wuh woh!
 772 2012-08-20 09:49:34 random_cat__ is now known as random_cat
 773 2012-08-20 09:58:48 iocor has joined
 774 2012-08-20 10:11:28 danbri has joined
 775 2012-08-20 10:13:44 bakh has joined
 776 2012-08-20 10:15:23 yellowhat has quit (Ping timeout: 272 seconds)
 777 2012-08-20 10:15:45 yellowhat has joined
 778 2012-08-20 10:26:33 bit01010101 has quit (Ping timeout: 260 seconds)
 779 2012-08-20 10:28:07 da2ce772 has joined
 780 2012-08-20 10:30:32 vampireb has joined
 781 2012-08-20 10:37:15 danbri has quit (Remote host closed the connection)
 782 2012-08-20 10:38:27 Cryo has joined
 783 2012-08-20 10:38:33 <Cryo> damn gavin
 784 2012-08-20 10:38:38 <Cryo> <tr><td>Obfuscated email</td><td>IP Address</td><td>Transaction ID</td></tr>
 785 2012-08-20 10:38:38 <Cryo> </thead>
 786 2012-08-20 10:38:38 <Cryo> <tr>
 787 2012-08-20 10:38:38 <Cryo> <td>cryonaor@gmail.com</td>
 788 2012-08-20 10:38:51 <Cryo> oh nm, you got me
 789 2012-08-20 10:39:20 <Cryo> braincell just read it as it should be
 790 2012-08-20 10:47:56 AlexWaters has quit (Quit: Leaving.)
 791 2012-08-20 10:52:14 roconnor__ has joined
 792 2012-08-20 10:53:12 leotreasure has joined
 793 2012-08-20 10:53:28 yellowhat has quit (Read error: Connection reset by peer)
 794 2012-08-20 10:53:39 yellowhat has joined
 795 2012-08-20 10:54:23 LuaKT has joined
 796 2012-08-20 10:54:23 LuaKT has quit (Changing host)
 797 2012-08-20 10:54:23 LuaKT has joined
 798 2012-08-20 10:54:32 roconnor_ has quit (Ping timeout: 265 seconds)
 799 2012-08-20 10:56:10 da2ce772 has quit (Ping timeout: 252 seconds)
 800 2012-08-20 10:57:01 t7 has quit (Ping timeout: 276 seconds)
 801 2012-08-20 10:59:35 hahuang65 has quit (Quit: Computer has gone to sleep.)
 802 2012-08-20 11:00:49 yellowhat has quit (Ping timeout: 265 seconds)
 803 2012-08-20 11:01:17 leotreasure_ has joined
 804 2012-08-20 11:03:31 leotreasure has quit (Ping timeout: 248 seconds)
 805 2012-08-20 11:03:31 leotreasure_ is now known as leotreasure
 806 2012-08-20 11:05:35 danbri has joined
 807 2012-08-20 11:05:35 [Tycho] has quit (Read error: Connection reset by peer)
 808 2012-08-20 11:08:18 slush1 has joined
 809 2012-08-20 11:17:27 Goilio has quit (Ping timeout: 272 seconds)
 810 2012-08-20 11:21:25 t7 has joined
 811 2012-08-20 11:23:44 gfinn has quit (Remote host closed the connection)
 812 2012-08-20 11:25:11 AlexWaters has joined
 813 2012-08-20 11:33:03 t7 has quit (Read error: Connection reset by peer)
 814 2012-08-20 11:35:18 gfinn has joined
 815 2012-08-20 11:35:23 Motest003 has joined
 816 2012-08-20 11:36:33 Motest031 has quit (Ping timeout: 260 seconds)
 817 2012-08-20 11:41:25 bitzero has joined
 818 2012-08-20 11:41:51 bitzero is now known as Guest9098
 819 2012-08-20 11:46:11 Nesetalis has quit (Read error: Connection reset by peer)
 820 2012-08-20 11:47:03 Nesetalis has joined
 821 2012-08-20 11:49:58 MC-Eeepc has joined
 822 2012-08-20 12:10:12 TD has joined
 823 2012-08-20 12:11:19 rdponticelli has joined
 824 2012-08-20 12:16:41 MC-Eeepc has quit (Ping timeout: 240 seconds)
 825 2012-08-20 12:24:15 vigilyn has joined
 826 2012-08-20 12:25:48 aq83 has quit (Ping timeout: 246 seconds)
 827 2012-08-20 12:35:25 Zarutian has joined
 828 2012-08-20 12:35:27 minimoose has joined
 829 2012-08-20 12:42:07 datagutt has joined
 830 2012-08-20 12:44:53 ageis has quit (Quit: http://ageispolis.net)
 831 2012-08-20 12:46:01 ageis has joined
 832 2012-08-20 12:49:27 <genjix_afk> hi, who is responsible for blockchain.info? are they on irc?
 833 2012-08-20 12:49:28 dvide has joined
 834 2012-08-20 12:55:42 <genjix_afk> nevermind. emailed him.
 835 2012-08-20 12:56:10 <sipa> very afk you seem!
 836 2012-08-20 12:59:59 Guest9098 has quit (Ping timeout: 252 seconds)
 837 2012-08-20 13:04:13 asa has quit (Remote host closed the connection)
 838 2012-08-20 13:05:36 asa has joined
 839 2012-08-20 13:05:51 iocor has quit (Ping timeout: 244 seconds)
 840 2012-08-20 13:08:48 iocor has joined
 841 2012-08-20 13:12:32 <Eliel> amiller: If you've read the ppcoin paper by now, you probably noticed this yourself, but to mine with the proof-of-stake you need to expend the coin-age in the process to make a block.
 842 2012-08-20 13:13:09 <Eliel> amiller: it makes sustained 51% attack impossible without really having 51%+
 843 2012-08-20 13:14:13 <Eliel> amiller: however, it seems to me you can mine future blocks now and know in advance when you'll be finding blocks.
 844 2012-08-20 13:15:49 one_zero has quit ()
 845 2012-08-20 13:17:10 <Eliel> so, without the centralized locking mechanism they're using, it's really not usable.
 846 2012-08-20 13:30:58 guruvan has quit (Remote host closed the connection)
 847 2012-08-20 13:31:00 guruvan- is now known as guruvan
 848 2012-08-20 13:31:43 guruvan_ has joined
 849 2012-08-20 13:32:20 roconnor__ is now known as roconnor
 850 2012-08-20 13:34:44 asa has quit (Remote host closed the connection)
 851 2012-08-20 13:35:08 <gmaxwell> Eliel: they're checkpointing instantly behind the chain head too.
 852 2012-08-20 13:35:40 <TD> er
 853 2012-08-20 13:35:45 <gmaxwell> (not only does nothing prevent them from purely using the centeralized checkpoints as the only consensus mechenism, thats actually what they're doing)
 854 2012-08-20 13:35:45 <TD> doesn't that defeat the point of a block chain?
 855 2012-08-20 13:36:19 <Eliel> yep
 856 2012-08-20 13:37:39 <Eliel> double-spends are simpler to pull out in their proof-of-stake system than in bitcoin because you can "mine in advance" to know the exact time when you'll find future blocks.
 857 2012-08-20 13:37:56 <epscy> what is proof of stake
 858 2012-08-20 13:38:01 <epscy> ppcoin needs a wiki
 859 2012-08-20 13:38:42 cande has joined
 860 2012-08-20 13:38:45 <Eliel> http://www.ppcoin.org/static/ppcoin-paper.pdf
 861 2012-08-20 13:38:46 <gmaxwell> In fact, their placement of a checkpoint _appears_ to have orphaned a block of mine.
 862 2012-08-20 13:39:16 <Eliel> gmaxwell: considering they seem to do it automatically, it'd mean the block that is orphaned is the one they don't see first.
 863 2012-08-20 13:39:21 <gmaxwell> s/a/at least a/
 864 2012-08-20 13:39:23 yellowhat has joined
 865 2012-08-20 13:39:53 <gmaxwell> Eliel: right right, just pointing out that they're not even attempting to use a decenteralized decision.
 866 2012-08-20 13:40:47 <Eliel> not quite a contender for bitcoin as it is right now.
 867 2012-08-20 13:41:11 <epscy> In order to facilitate the computation of coin age, we introduced a timestamp field into
 868 2012-08-20 13:41:13 <epscy> each transaction. Block timestamp and transaction timestamp related protocols are
 869 2012-08-20 13:41:16 <epscy> strengthened to secure the computation of coin age.
 870 2012-08-20 13:41:24 <epscy> i would like to know more about this
 871 2012-08-20 13:41:26 <cande> Eliel, very interesting
 872 2012-08-20 13:41:27 <Eliel> even if I like how they implemented the proof-of-stake mining process.
 873 2012-08-20 13:41:38 <epscy> i thought the timestamp in bitcoin wasn't very reliable
 874 2012-08-20 13:41:44 <sipa> right, it sounds like an interesting experiment
 875 2012-08-20 13:42:36 <tonikt> Guys, I've been using the current master branch, built for Win7,64 - I've had no problems  for weeks. but today it stopped working. The debug file shows taht everything is fine but the gui is just completely frozen - just a window's frame with white area inside
 876 2012-08-20 13:42:51 <tonikt> Does it tell you anything?
 877 2012-08-20 13:43:02 <sipa> tonikt: what's the last thing in debug.log?
 878 2012-08-20 13:43:04 <tonikt> The official relese still launches just fine
 879 2012-08-20 13:43:23 <tonikt> The log is being written all the time
 880 2012-08-20 13:43:29 <tonikt> Seems like the node itself is working
 881 2012-08-20 13:43:35 <sipa> ok, so it's just the GUI that is frozen
 882 2012-08-20 13:43:35 <tonikt> Only the giu is frozen
 883 2012-08-20 13:44:13 vampireb_ has joined
 884 2012-08-20 13:44:15 <tonikt> I will try to start it in server mode and let you know if RPC works
 885 2012-08-20 13:44:43 <sipa> tonikt: if it's reproducible, can you try to find out approximately since what commit it broke?
 886 2012-08-20 13:45:16 <tonikt> I use exactly te same code as like 2 weeks ago - and it only stopped working as fo today
 887 2012-08-20 13:45:40 <tonikt> The exe has a timestamp of August 5th
 888 2012-08-20 13:45:46 <sipa> oh
 889 2012-08-20 13:45:53 <tonikt> RPC works just fine
 890 2012-08-20 13:46:13 <tonikt> If you want I can change code, add some debugs, and recompile
 891 2012-08-20 13:46:44 DamascusVG has joined
 892 2012-08-20 13:46:54 <tonikt> I think it started happening after I added a new addres to the address book
 893 2012-08-20 13:47:04 <tonikt> But it may as well be a coincidence
 894 2012-08-20 13:48:01 <sipa> wumpus: can you help tonikt?
 895 2012-08-20 13:48:18 Turingi has joined
 896 2012-08-20 13:48:30 <tonikt> to give you an impression it looks like this: http://img52.imageshack.us/img52/6637/clipboard1q.png
 897 2012-08-20 13:48:38 yellowhat has quit (Ping timeout: 240 seconds)
 898 2012-08-20 13:48:45 <tonikt> but the node itself, including RPC is working just fine
 899 2012-08-20 13:51:19 <TD> this "bitparking" that only includes like 8 or 9 transactions is weird
 900 2012-08-20 13:51:29 <TD> i wonder what their ruleset is
 901 2012-08-20 13:52:06 <tonikt> anyway: it is 100% reproductible ATM, the same exe was workinng for 2 weeks without any problems, and the last official build does not have the issue (lukcily for me ) :)
 902 2012-08-20 13:52:32 <sipa> tonikt: and if you move your datadir out of the way, and start from scratch?
 903 2012-08-20 13:52:48 <sipa> (don't delete it though, just move it temporarily while bitcoin is not running)
 904 2012-08-20 13:52:49 <gmaxwell> might want to have tonikt compile with the deadlock detection
 905 2012-08-20 13:52:59 <sipa> good point
 906 2012-08-20 13:53:08 <tonikt> how do I swicth it on?
 907 2012-08-20 13:53:22 <sipa> add -DDEBUG_LOCKORDER to the compile command line
 908 2012-08-20 13:53:34 <tonikt> ok - i will get back to you
 909 2012-08-20 13:53:45 <sipa> thanks!
 910 2012-08-20 13:55:47 yellowhat has joined
 911 2012-08-20 13:57:50 <Eliel> amiller: one thing I've been wondering about. Could it be possible to build a consensus algorithm that's based on detecting the need to resync by comparing current UTXO merkle root hashes between nodes and if they differ, they find the last common ancestor UTXO merkle root and "resync".
 912 2012-08-20 13:58:45 <sipa> Eliel: that should be possible
 913 2012-08-20 13:58:48 aq83 has joined
 914 2012-08-20 13:59:17 pickett_ has quit (Remote host closed the connection)
 915 2012-08-20 13:59:34 <sipa> but whether it can be done efficiently... unsure, as you'll need quite some roundtrips before the different parts are locates
 916 2012-08-20 13:59:44 <Eliel> the hard part is tuning the parameters so that it converges towards whole network agreement with reasonable speed in case there's conflicts.
 917 2012-08-20 14:00:10 <tonikt> I can also try building it with gitian on my linux machine. Is there a way to modify the yml file so it takes the HEAD instead of the commit parameter?
 918 2012-08-20 14:01:02 * Eliel wonders if the proof-of-work algorithm could come into play in resolving conflicts and only when resolving conflicts.
 919 2012-08-20 14:01:18 <sipa> tonikt: i have a wrapper script around gitian that copies my working dir into the gitian builder, and takes a commit id as command-line argument
 920 2012-08-20 14:01:41 <sipa> tonikt: so it can build from any repository you have fetched, and any commit
 921 2012-08-20 14:03:14 <sipa> i believe devrandom added support for something similar already in later versions of gitian though
 922 2012-08-20 14:03:26 <tonikt> sipa: ok.. can you show me this script?
 923 2012-08-20 14:03:38 <sipa> not sure whether it still works, but sec
 924 2012-08-20 14:04:10 pickett has joined
 925 2012-08-20 14:04:27 copumpkin has joined
 926 2012-08-20 14:05:26 <sipa> tonikt: http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt
 927 2012-08-20 14:05:53 danbri has quit (Remote host closed the connection)
 928 2012-08-20 14:06:06 <tonikt> sipa: thx, I will have a look..
 929 2012-08-20 14:06:48 danbri has joined
 930 2012-08-20 14:06:59 danbri has quit (Remote host closed the connection)
 931 2012-08-20 14:07:16 <doublec> TD: that's me
 932 2012-08-20 14:07:31 <TD> what is you?
 933 2012-08-20 14:07:36 <doublec> TD: bitparking
 934 2012-08-20 14:07:38 <TD> ah ok
 935 2012-08-20 14:07:42 <TD> so why are you including so few transactions?
 936 2012-08-20 14:07:56 <doublec> back when satoshidice was causing a large backlog it was causing issues with the pool
 937 2012-08-20 14:08:18 <tonikt> with -DDEBUG_LOCKORDER it just crashes right away - before even writing anything to the log file. doesnt even create the data dir after I remove it
 938 2012-08-20 14:08:19 <doublec> due to the interaction with merge mining (frequent blocks on an alt chain)
 939 2012-08-20 14:08:21 MC-Eeepc has joined
 940 2012-08-20 14:08:28 <TD> don't you think 10 txns or less is a bit excessive? why not just go all the way and include no transactions at all like a botnet?
 941 2012-08-20 14:08:33 <doublec> resulting in lots of traversals of the transaction list
 942 2012-08-20 14:08:44 <tonikt> let me try the gitian build
 943 2012-08-20 14:08:57 MC-Eeepc has quit (Client Quit)
 944 2012-08-20 14:08:58 Motest003 has quit (Ping timeout: 240 seconds)
 945 2012-08-20 14:08:59 <sipa> tonikt: what OS?
 946 2012-08-20 14:09:03 <doublec> so I have a had a hard limit of transactions in the memorypool
 947 2012-08-20 14:09:10 <tonikt> Windows 7 Ultimate, 64 bit
 948 2012-08-20 14:09:30 <doublec> rather, I'd limit the working through the pool picking transactions
 949 2012-08-20 14:09:46 <doublec> but the limit is set before it applies the other rules for not including transactions
 950 2012-08-20 14:09:51 <doublec> so it ends up quite a bit shorter than my limit
 951 2012-08-20 14:10:04 <doublec> I've fixed it but haven't restarted my pool since then. it'll be picked up when that happens.
 952 2012-08-20 14:11:00 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
 953 2012-08-20 14:12:49 <TD> ok
 954 2012-08-20 14:13:44 <doublec> an unfortunate result of a quick fix basically
 955 2012-08-20 14:13:50 MC-Eeepc has joined
 956 2012-08-20 14:14:37 <gmaxwell> tonikt: what messages does it output/log when it crashes?
 957 2012-08-20 14:15:06 <tonikt> It's just a regulat windows crash window
 958 2012-08-20 14:15:24 <gmaxwell> tonikt: launch bitcoin-qt from the commandline so you can see its output.
 959 2012-08-20 14:16:04 cande has quit (Read error: Connection reset by peer)
 960 2012-08-20 14:16:45 vampireb_ has quit (Quit: Lost terminal)
 961 2012-08-20 14:16:57 cande has joined
 962 2012-08-20 14:17:02 <tonikt> gmaxwell: there is no output - windows starts it and returns to command prompt. in the background the crash windows appread and when i choose to see details I get this: http://pastebin.com/YEZFYYBr
 963 2012-08-20 14:17:07 <gavinandresen> So... any reason we can't spin a 0.7 release candidate 1?
 964 2012-08-20 14:17:26 vampireb_ has joined
 965 2012-08-20 14:17:28 <sipa> gavinandresen: let me have quick look at the pullreq list
 966 2012-08-20 14:18:44 <gmaxwell> tonikt: anything in the debug.log?
 967 2012-08-20 14:18:57 att has joined
 968 2012-08-20 14:19:26 <tonikt> gmaxwell: no - it crashes right away. doesnt even create the data folder after I deleted it
 969 2012-08-20 14:19:36 <tonikt> not to mention the debug.log
 970 2012-08-20 14:19:55 <sipa> gavinandresen: i would have liked to see #1672, #1647, #1641, #1526 in 0.7 still
 971 2012-08-20 14:20:24 <gmaxwell> woops. I forgot to do that refactoring on 1672.
 972 2012-08-20 14:20:46 <jgarzik> gavinandresen: as gmaxwell said the other day, the pull reqs on the 0.7 list all seem to require updates.  I'd say go for it.
 973 2012-08-20 14:21:03 <jgarzik> there are lists, but without the pull reqs progressing, I think those lists can be ignored, frankly.
 974 2012-08-20 14:22:05 <gmaxwell> I'm unhappy about the recent seemingly more frequent reports of stuck nodes, but I've made no progress in identifying the cause.  This is perhaps a sign that we should expect a 0.7.1 to be soon following in any case.
 975 2012-08-20 14:22:08 <jgarzik> gavinandresen: ACK sipa's list
 976 2012-08-20 14:23:36 <jgarzik> gmaxwell gavinandresen: if you two can add ACKs to sipa's ACK for https://github.com/bitcoin/bitcoin/pull/1641 we can pull that right now
 977 2012-08-20 14:23:53 <gmaxwell> WRT stuck nodes:
 978 2012-08-20 14:23:53 <gmaxwell> 07:50 < Eliel> it's also saying "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
 979 2012-08-20 14:23:56 <gmaxwell> 07:18 < DrHaribo> Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
 980 2012-08-20 14:24:00 <gmaxwell> 00:47 < cande> Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
 981 2012-08-20 14:24:03 <gmaxwell> 12:47 < question> the message below in the wallet where normally the block counts : Warning : displayed transactions may not be correct ! you may need to upgrade , or other nodes need to upgrad
 982 2012-08-20 14:24:56 <TD> gmaxwell: general performance degradation? andreas was telling me bitcoin-qt has become barely usable for him
 983 2012-08-20 14:25:18 <sipa> those warnings probably mean a corrupted block...
 984 2012-08-20 14:25:22 <sipa> *index
 985 2012-08-20 14:25:33 DamascusVG has joined
 986 2012-08-20 14:26:05 <gmaxwell> Right, but multiple people dying at the sameish point?
 987 2012-08-20 14:26:34 <gavinandresen> jgarzik: 1641 acked
 988 2012-08-20 14:26:54 <sipa> gmaxwell: weird, indeed
 989 2012-08-20 14:27:17 <gavinandresen> sipa: 1647 (child pays for parent) needs very careful code review before pulling
 990 2012-08-20 14:27:27 <gavinandresen> (potential DoS attack lurking there)
 991 2012-08-20 14:27:33 <sipa> gavinandresen: yes, that's why i haven't acked it myself; but i still would have liked it in 0.7
 992 2012-08-20 14:27:45 <sipa> but if that's not doable, skip it for now
 993 2012-08-20 14:28:01 <gmaxwell> jgarzik: 1641 you merged it before I could ack, ACK in any case.:)
 994 2012-08-20 14:28:16 <sipa> posthumous ack!
 995 2012-08-20 14:29:04 <jgarzik> thanks
 996 2012-08-20 14:29:13 <jgarzik> as long as gavinandresen is happy with #1526, I am too
 997 2012-08-20 14:29:43 <gavinandresen> 1526 might be controversial.... I haven't publicized the change
 998 2012-08-20 14:30:02 <jgarzik> gavinandresen: it got discussed on the ML as a BIP
 999 2012-08-20 14:30:32 <sipa> not too much discussion, iirc
1000 2012-08-20 14:30:38 <gmaxwell> Well, we'd still have the RC time to further discuss it.
1001 2012-08-20 14:30:45 <gavinandresen> ok, then I'm happy....
1002 2012-08-20 14:30:55 <jgarzik> hrm
1003 2012-08-20 14:31:01 <jgarzik> maybe that was private discussion :/
1004 2012-08-20 14:31:20 <sipa> if people feel there hasn't been enough discussion, i'd rather wait with merging
1005 2012-08-20 14:31:28 <jgarzik> nvm
1006 2012-08-20 14:31:37 <jgarzik> I posted it to bitcoin-devel on July 6
1007 2012-08-20 14:32:08 <gmaxwell> sipa: I feel that there won't be much discussion because it's a fairly boring change. :)
1008 2012-08-20 14:32:15 <jgarzik> indeed
1009 2012-08-20 14:32:16 <sipa> right
1010 2012-08-20 14:32:28 <gavinandresen> One reason NOT to pull it is if we'd like to bundle in some other change to block.version==2
1011 2012-08-20 14:32:40 <gavinandresen> ... but we've got plenty of versions to play with, so that's not a strong reason
1012 2012-08-20 14:32:45 * jgarzik reviews the m-l discussion; no nak's, just some light "why?" discussion
1013 2012-08-20 14:32:57 <jgarzik> I say go for it
1014 2012-08-20 14:33:15 <gavinandresen> easier to ask forgiveness than permission....
1015 2012-08-20 14:33:15 <jgarzik> been out there on wiki and m-l for 2 months
1016 2012-08-20 14:33:44 <gmaxwell> For prudence sake there should probably be a reminder about it.
1017 2012-08-20 14:33:44 <jgarzik> personally I would like to require that all coinbases be well formed, but let's not block #1526 for that
1018 2012-08-20 14:34:03 <gavinandresen> gmaxwell: go for it (post a reminder)
1019 2012-08-20 14:35:19 <gmaxwell> gavinandresen: better to do after its merged, but I'll do so.
1020 2012-08-20 14:35:23 <gavinandresen> jgarzik: well-formed coinbases sound like a good idea to me... could be part of the AreInputsStandard() check when they get spent......
1021 2012-08-20 14:36:19 <sipa> gavinandresen: not the right place to do so, imho
1022 2012-08-20 14:36:36 <gmaxwell> (a reminder is less useful if people will continue to ignore it. :) at least if it goes with a merge it'll be clear you can't just ignore it)
1023 2012-08-20 14:36:55 * jgarzik would prefer to do it with the rest of the block checks -- just declare "v3 + invalid coinbase == invalid block"
1024 2012-08-20 14:37:01 <sipa> jgarzik: indeed
1025 2012-08-20 14:37:05 <jgarzik> or v2 etc.
1026 2012-08-20 14:37:11 <gavinandresen> yeah, that's the right way to do it.
1027 2012-08-20 14:37:15 Cablesaurus has quit (Quit: There's nothing dirtier then a giant ball of oil)
1028 2012-08-20 14:37:32 <gmaxwell> jgarzik+1. Really, it would make made sense to do it in v2, esp since both are changing the coinbase rules. But, meh. seems too late now.
1029 2012-08-20 14:37:35 <sipa> sorry to bring it up again, but when you're using a UTXO set to validate things, you don't have any inputs anymore
1030 2012-08-20 14:38:25 * jgarzik would prefer v2 to require well formed coinbase too :)
1031 2012-08-20 14:38:37 <jgarzik> but I agree it (a) seems late and (b) might complicate miner deployment
1032 2012-08-20 14:39:02 <sipa> i agree, and i'm fine with postponing that requirement
1033 2012-08-20 14:39:10 <sipa> we shouldn't rush something like that
1034 2012-08-20 14:39:26 <jgarzik> it definitely breaks a few oddball merged mining setups
1035 2012-08-20 14:39:38 <jgarzik> _most_ coinbases remain well formed, which is good
1036 2012-08-20 14:39:51 <jgarzik> well over 60%
1037 2012-08-20 14:39:57 <sipa> only 60%?
1038 2012-08-20 14:40:08 <sipa> wow,  i thought only exceptions used non-well formed coinbases
1039 2012-08-20 14:40:35 <jgarzik> sipa: don't read too much into that number, that's just my from-memory number.  it would be much higher if I had real data in front of me
1040 2012-08-20 14:40:46 <sipa> ok
1041 2012-08-20 14:40:51 * jgarzik is just being conservative, and doesn't want to claim "90%!" without having checked in 3 weeks
1042 2012-08-20 14:41:00 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
1043 2012-08-20 14:41:03 <sipa> right, sure
1044 2012-08-20 14:41:43 <jgarzik> whee, I can add "send mempool at startup" code to pynode now
1045 2012-08-20 14:41:50 <jgarzik> let's fill that mempool right up
1046 2012-08-20 14:46:16 * gavinandresen fixing unit tests and signed/unsigned warnings for height-in-coinbase pull.....
1047 2012-08-20 14:48:27 <roconnor> sipa: what is a well formed coinbase?
1048 2012-08-20 14:49:01 <sipa> roconnor: one where the coinbase input is a push-only script
1049 2012-08-20 14:49:53 Joric has joined
1050 2012-08-20 14:49:53 Joric has quit (Changing host)
1051 2012-08-20 14:49:53 Joric has joined
1052 2012-08-20 14:54:20 <gavinandresen> 1526 updated; Matt's pull tester will auto-build it fairly soon, yes?
1053 2012-08-20 14:54:31 <sipa> it should
1054 2012-08-20 14:55:54 <TD> gavinandresen: what's the DoS risk in 1647?
1055 2012-08-20 14:56:00 <TD> gavinandresen: just generally more disk load or what?
1056 2012-08-20 14:56:45 <gavinandresen> TD: crafting a set of transactions that require O(n^2) time to determine fee or priority
1057 2012-08-20 14:56:59 vampireb_ has quit (Quit: Lost terminal)
1058 2012-08-20 14:58:06 <jgarzik> sipa: "push only" sounds too tight for coinbase.   I was thinking a well-formed coinbase would simply be "all recognized opcodes" (which includes all PUSHDATA opcodes)
1059 2012-08-20 14:58:11 vampireb_ has joined
1060 2012-08-20 14:58:17 <gmaxwell> gavinandresen: that _should_ be addressed by the code giving up after some amount of work, I guess; but it doesn't do that now.
1061 2012-08-20 14:59:08 <gavinandresen> gmaxwell: yes, limiting to immediate parents (or some recursive depth limit) would make me more comfortable.
1062 2012-08-20 14:59:30 <TD> gavinandresen: surely the work of calculating fees/priority is trivial compared to actually verifying the tx itself
1063 2012-08-20 14:59:52 <gmaxwell> TD: I can flood you with unbounded numbers of txn.
1064 2012-08-20 15:00:05 <TD> yes. but that is already possible
1065 2012-08-20 15:00:05 <gavinandresen> luke had a bug in a prior version of that code that made it susceptible to a DoS
1066 2012-08-20 15:00:08 <gmaxwell> and n^2 checking effort has a way of catching up with any constant factor difference.
1067 2012-08-20 15:00:15 <TD> oh, ok
1068 2012-08-20 15:04:33 Maccer has quit (Excess Flood)
1069 2012-08-20 15:04:53 <sipa> jgarzik: well, as coinbases are never executed, allowing non-push operations shouldn't be a problem
1070 2012-08-20 15:05:13 <sipa> not sure there's too much use for it, though
1071 2012-08-20 15:05:39 <jgarzik> sipa: I admit I don't see a use case, but don't want to be overly restrictive and close off possible avenues for experimentation later.
1072 2012-08-20 15:05:55 <sipa> agree
1073 2012-08-20 15:08:08 <Joric> regarding binary-encoded messages like the last here http://blockchain.info/address/1EMLwAwseowTkDtKnEHRKrwQvzi4HShxSX, will miners process a transaction with several outputs to the _same_ address?
1074 2012-08-20 15:09:49 <Joric> maybe it's not possible for some reason i personally don't see why not
1075 2012-08-20 15:10:08 <sipa> why would that be a problem
1076 2012-08-20 15:10:08 <sipa> ?
1077 2012-08-20 15:10:32 sunshinehappy has joined
1078 2012-08-20 15:10:33 <sipa> (i see no reason why that would be a problem)
1079 2012-08-20 15:11:09 <Joric> idk someone sent a bunch of tiny transactions to https://blockchain.info/address/1DkyBEKt5S2GDtv7aQw6rQepAvnsRyHoYM it would look better if it was a single tx
1080 2012-08-20 15:11:53 <sipa> the "bunch of" and the "tiny" may be a problem, but the same address shouldn't :)
1081 2012-08-20 15:12:44 <Joric> another idea for pruning )
1082 2012-08-20 15:13:08 <Joric> though i didn't see those transactions in the wild yet
1083 2012-08-20 15:13:17 <gavinandresen> Not a problem for miners. The sendmany RPC command won't let you do that, though, so they're non-trivial to create.
1084 2012-08-20 15:13:52 <gavinandresen> (actually, does the GUI let you create a bunch of sends to the same address in one transaction?)
1085 2012-08-20 15:13:59 ASukharev3318 is now known as asuk
1086 2012-08-20 15:14:25 <Joric> blockchain.info wallet can construct those just tried it doesn't check outputs
1087 2012-08-20 15:15:35 [\\\] is now known as gigatubes
1088 2012-08-20 15:15:50 gigatubes is now known as gigatube
1089 2012-08-20 15:16:13 <gmaxwell> gavinandresen: the rpc doesn't dunno about the gui.
1090 2012-08-20 15:17:52 user__ has joined
1091 2012-08-20 15:19:26 Maccer has joined
1092 2012-08-20 15:21:30 rickbauss has joined
1093 2012-08-20 15:21:59 <jgarzik> SatoshiDICE IPO'ing, cute: https://bitcointalk.org/index.php?topic=101902.0
1094 2012-08-20 15:22:44 <Joric> ppl will get a ton of money to invest today after 22:00 UTC
1095 2012-08-20 15:25:22 <gmaxwell> jgarzik: I boggle at that, what terribly evil things do they need a ton of additional coin. Their 7kbtc in profits in the last couple months aren't enough to finance .. what?
1096 2012-08-20 15:26:07 <BlueMatt> Luke-Jr/gmaxwell: even I dont use my own dnsseeder any more...
1097 2012-08-20 15:26:11 <sipa> maybe they could use it to pay all those who would otherwise stop running a full node because of their bloat?
1098 2012-08-20 15:26:16 <Joric> ppl should buy it out and vote for liquidation :D
1099 2012-08-20 15:26:27 Rabbit67890 has joined
1100 2012-08-20 15:26:54 <BlueMatt> (diversity would be nice, but not at the expense of that crap...)
1101 2012-08-20 15:27:04 <jgarzik> 22:00 UTC is pirate payday?
1102 2012-08-20 15:27:07 DiabloD3 has joined
1103 2012-08-20 15:27:16 <jgarzik> I predict pirate pays out 25% of BS&T, and then fades away
1104 2012-08-20 15:27:29 <jgarzik> enough for people to say "he's paying"
1105 2012-08-20 15:27:44 vampireb_ is now known as vampire
1106 2012-08-20 15:28:07 <gmaxwell> Joric: they're only selling 10%, and at remarkably high prices.
1107 2012-08-20 15:28:37 <BlueMatt> TD: saw the merge, nice...there are a few others in fullscripts that I never got around to moving that may be interesting, but none of them are too exciting
1108 2012-08-20 15:28:43 <BlueMatt> eg "Implement PUSHDATA4 and check max script size in Script.parse"
1109 2012-08-20 15:28:48 <TD> ok
1110 2012-08-20 15:28:48 <BlueMatt> or "Print any opcode in Script.toString, adding Script.getOpCodeName"
1111 2012-08-20 15:28:54 <jgarzik> whee.  pynode is now running protover 60002, and snarfs mempool contents at startup
1112 2012-08-20 15:28:57 asa has joined
1113 2012-08-20 15:28:57 <TD> if you rebase them i'll take them
1114 2012-08-20 15:29:00 <TD> jgarzik: sweet!
1115 2012-08-20 15:29:09 vampireb has quit (Disconnected by services)
1116 2012-08-20 15:29:16 vampire is now known as vampireb
1117 2012-08-20 15:29:29 att has quit (Ping timeout: 255 seconds)
1118 2012-08-20 15:29:40 danbri has joined
1119 2012-08-20 15:31:17 <gmaxwell> Joric: assuming their projected revenue of 33,000 BTC/yr, their _lowest_ share price will take about 10 years to pay itself back.
1120 2012-08-20 15:32:16 <jgarzik> "The IPO is occurring exclusively on MPEx"  What the heck is MPEx?
1121 2012-08-20 15:32:51 <jgarzik> maybe this is an MPEx promo
1122 2012-08-20 15:33:07 <sipa> jgarzik: so that's in 5.5 hours?
1123 2012-08-20 15:33:15 <sipa> 6.5
1124 2012-08-20 15:33:40 <jgarzik> sipa: I dunno, it's what Joric said
1125 2012-08-20 15:33:55 <sipa> ah
1126 2012-08-20 15:34:48 <jgarzik> (tangent)
1127 2012-08-20 15:35:09 <jgarzik> I fear SatoshiDICE has started the trend of using bitcoin as messaging protocol for games
1128 2012-08-20 15:35:21 <Joric> http://polimedia.us/bitcoin/mpex.php?mpsic=S.DICE <- mpex
1129 2012-08-20 15:35:36 toffoo has quit ()
1130 2012-08-20 15:36:07 <Joric> that new satoshidice design looks like an ordinary scam site
1131 2012-08-20 15:36:31 <wumpus> gavinandresen: no, it doesn't, it gives an error if you try to send to the same address twice in one transaction
1132 2012-08-20 15:36:43 <gavinandresen> wumpus: good
1133 2012-08-20 15:37:06 <gavinandresen> wumpus: any must-haves on your list for a 0.7 rc1 release?
1134 2012-08-20 15:37:39 <wumpus> imo we're ready
1135 2012-08-20 15:37:50 gfinn has quit (Ping timeout: 276 seconds)
1136 2012-08-20 15:37:58 <sipa> wumpus: you saw tonikt's problem above?
1137 2012-08-20 15:38:01 <wumpus> though we need to merge messages from transifex 
1138 2012-08-20 15:38:04 <gavinandresen> good.  That means I need to figure out how I broke my OSX Qt build environment.....
1139 2012-08-20 15:38:35 <wumpus> sipa: yes, but I don't recognize it
1140 2012-08-20 15:38:39 <jgarzik> I hoped that somebody would come up with a distributed, GPG-signed version of GLBSE.  Doesn't look like MPEx is it.
1141 2012-08-20 15:38:54 <wumpus> sipa: also have no idea what could cause it
1142 2012-08-20 15:38:58 slush has quit (Ping timeout: 246 seconds)
1143 2012-08-20 15:39:41 <sipa> wumpus: too bad; hope we get more reports from the RC
1144 2012-08-20 15:39:59 <wumpus> he should probably try to interrupt the running process and see where it's stuck
1145 2012-08-20 15:40:09 <Joric> help > debug window > information > show command line options is not resizable, it's painful to read
1146 2012-08-20 15:40:45 <wumpus> it's a standard qt message box, those are not resizable
1147 2012-08-20 15:40:56 <TD> jgarzik: did you read the stuff about distributed bond markets i wrote? if not my talk at the london conf will cover it
1148 2012-08-20 15:41:05 <jgarzik> my GLBSE idea:  broadcast orders <somehow>.  sign bitcoin-for-asset + asset-for-bitcoin transaction (a single trade between two parties), and broadcast that.
1149 2012-08-20 15:41:10 <TD> bonds and stocks are pretty similar in that respect
1150 2012-08-20 15:41:21 * jgarzik was about to write... "kinda like what TD posted" ;-)
1151 2012-08-20 15:41:24 <TD> heh
1152 2012-08-20 15:42:16 darkskiez has quit (Ping timeout: 245 seconds)
1153 2012-08-20 15:42:19 <wumpus> and that feature is not really worth making a custom window for, it was originally meant only as a workaround for windows when there is no stdout
1154 2012-08-20 15:42:28 <jgarzik> anybody can create an asset with X shares, just as easy as creating a new private key.  once created, you cannot change the number of shares for that object, though you can send (trade) them to another party.
1155 2012-08-20 15:42:41 <jgarzik> TD: do you have a link?  I read it when first posted, but don't have it handy
1156 2012-08-20 15:43:15 <TD> https://bitcointalk.org/index.php?topic=92421.0
1157 2012-08-20 15:43:26 <TD> it basically models bonds / stocks as https://en.bitcoin.it/wiki/Smart_Property
1158 2012-08-20 15:43:52 <TD> somebody emailed me about a distributed version of GLBSE a while ago
1159 2012-08-20 15:44:03 <TD> i explained how to do it but never heard back. a lot of people find distributed app design tough, i think
1160 2012-08-20 15:44:08 <TD> vs just throwing together a web app
1161 2012-08-20 15:45:05 Rabbit67890 is now known as RainbowDashh
1162 2012-08-20 15:45:15 <jgarzik> TD: making a distributed app also requires a lot of faith for potentially little direct monetary payback :)
1163 2012-08-20 15:45:26 <TD> yeah
1164 2012-08-20 15:45:39 <TD> i don't think we'll see a lot of distributed apps being written until the assurance contract stuff is worked out
1165 2012-08-20 15:46:01 mmoya has quit (Ping timeout: 245 seconds)
1166 2012-08-20 15:46:23 <BlueMatt> great chicken-and-egg problem, that
1167 2012-08-20 15:47:51 osxorgate has quit (Remote host closed the connection)
1168 2012-08-20 15:49:38 gfinn has joined
1169 2012-08-20 15:52:06 <BlueMatt> TD: ok, pushed another few useful commits to the top
1170 2012-08-20 15:52:14 darkskiez has joined
1171 2012-08-20 15:52:24 <BlueMatt> the MPI one is essentially useless until later,  but the ones before it may be good to pull
1172 2012-08-20 15:52:27 mmoya has joined
1173 2012-08-20 15:52:47 <TD> this is the fullverif branch still?
1174 2012-08-20 15:52:51 <BlueMatt> yea
1175 2012-08-20 15:53:01 <TD> got it
1176 2012-08-20 15:54:57 RainbowDashh is now known as Rabbit67890
1177 2012-08-20 15:55:38 <TD> wow
1178 2012-08-20 15:55:42 <TD> the openssl thing is obscure
1179 2012-08-20 15:55:46 <TD> how did you find out about that?
1180 2012-08-20 15:55:53 <BlueMatt> a tx in the chain failed
1181 2012-08-20 15:56:18 <TD> fascinating
1182 2012-08-20 15:56:26 <BlueMatt> and gmaxwell pointed me to rconnor who pointed me there
1183 2012-08-20 15:56:27 <TD> i really worry about people mining on an alternative implementation
1184 2012-08-20 15:56:35 <BlueMatt> yea
1185 2012-08-20 15:56:37 <TD> really subtle details like this could result in unexpected chain splits
1186 2012-08-20 15:57:18 <BlueMatt> yea, I liked gmaxwell's point of, big miners would only mine txes/blocks/etc that passed on multiple implementations
1187 2012-08-20 15:57:24 <TD> even if you don't mine, if you're doing full verification on an alt implementation and there's a bug like this you would be disconnected from the network for a while until it's fixed
1188 2012-08-20 15:57:28 <TD> hmm
1189 2012-08-20 15:57:33 <TD> yeah. chalk it up to mining professonalism
1190 2012-08-20 15:57:38 <BlueMatt> heh
1191 2012-08-20 15:57:40 <TD> damn, i wish we had a bitcoin-miners-announce mailing list :(
1192 2012-08-20 15:57:48 <TD> i don't trust miners to read the forums, there's too much noise there
1193 2012-08-20 15:58:04 <sipa> TD: that's not a bad idea, actually
1194 2012-08-20 15:58:22 <BlueMatt> we have a bitcoin-announce, dont we? do we use it for anything anyway?
1195 2012-08-20 15:58:54 <TD> not sure. a miners only list might encourage more miners to sign up
1196 2012-08-20 15:59:01 <denisx> when you say miners you mean pool operators?
1197 2012-08-20 15:59:04 <BlueMatt> true
1198 2012-08-20 15:59:14 <TD> miners == people who run full bitcoin nodes that vend work
1199 2012-08-20 15:59:21 <TD> so pool operators, solo miners, p2pool users
1200 2012-08-20 16:00:19 <BlueMatt> first ever good recommendation from amazon: student solutions manual of a book I just bought
1201 2012-08-20 16:01:00 <TD> merged, thanks
1202 2012-08-20 16:04:02 <Joric> sipa, do you have students btw? PhD implies teaching )
1203 2012-08-20 16:04:15 att has joined
1204 2012-08-20 16:04:21 <copumpkin> Joric: not always
1205 2012-08-20 16:04:24 <copumpkin> at all
1206 2012-08-20 16:04:31 <copumpkin> fortunately or not :P
1207 2012-08-20 16:04:36 <sipa> Joric: i did, but i finished in december, and i'm not at the university anymore
1208 2012-08-20 16:04:41 da2ce7 has quit (Remote host closed the connection)
1209 2012-08-20 16:04:54 <sipa> also, not particularly interesting courses
1210 2012-08-20 16:05:07 <tonikt> the new code does not compile with boost 1.47 anymore - right?
1211 2012-08-20 16:05:24 <sipa> BlueMatt should know that
1212 2012-08-20 16:05:34 <tonikt> checkpoints.cpp:60: error: âBOOST_REVERSE_FOREACHâ was not declared in this scope
1213 2012-08-20 16:05:36 da2ce7 has joined
1214 2012-08-20 16:06:24 <BlueMatt> I wasnt aware of any issues with boost 1.47, in fact, my system is 1.49
1215 2012-08-20 16:07:44 gfinn has quit (Ping timeout: 276 seconds)
1216 2012-08-20 16:08:27 <jgarzik> TD: combining the distributed bonds with P2SH might be interesting
1217 2012-08-20 16:09:03 * jgarzik wonders if P2SH might assist in enforcing policy
1218 2012-08-20 16:09:35 da2ce7 has quit (Remote host closed the connection)
1219 2012-08-20 16:09:35 <tonikt> Do you guys maybe have this boost-win32-1.49.0-gitian2.zip for windows?
1220 2012-08-20 16:09:41 <tonikt> It would save me some time
1221 2012-08-20 16:09:48 <TD> why?
1222 2012-08-20 16:09:53 <TD> afaict P2SH makes things more complicated
1223 2012-08-20 16:10:04 <TD> the protocol relies on being able to read outputs to find relevant transactions in the chain
1224 2012-08-20 16:10:15 <TD> so you can't use P2SH for those
1225 2012-08-20 16:10:23 <Anduck> guys
1226 2012-08-20 16:10:28 <TD> (unless you have a separate data store and use txid as the key)
1227 2012-08-20 16:10:29 <Anduck> how can i find out network id?
1228 2012-08-20 16:10:41 <sipa> Anduck: what is a network id?
1229 2012-08-20 16:10:51 <Anduck> blockchain network id or something
1230 2012-08-20 16:10:56 <sipa> context?
1231 2012-08-20 16:10:59 <Anduck> its different for testnet
1232 2012-08-20 16:11:05 <Anduck> and different for real bitcoin blockchain
1233 2012-08-20 16:11:16 <TD> do you mean the version byte in addresses?
1234 2012-08-20 16:11:20 da2ce7 has joined
1235 2012-08-20 16:11:22 <sipa> ah, 0 for realnet addresses and 128 for testnet
1236 2012-08-20 16:11:54 * jgarzik still thinks there needs to be an alt-data chain or fast-transaction chain, for trading applications.  Here's an idea: merge-mined chain of small data items, all of which carry an expiration date of no farther than 7 days in the future.  Publish signed messages there, rather than the main bitcoin chain.  Distributed entities + multisig could review the alt-chain contents, and then sign big transactions on the bitcoin network every 60 sec
1237 2012-08-20 16:12:18 <BlueMatt> or does he mean the pchMessageStart
1238 2012-08-20 16:12:29 <jgarzik> establish a market to compete to be one of these validating signature entities
1239 2012-08-20 16:12:55 <TD> you could also just use a DHT
1240 2012-08-20 16:13:04 <jgarzik> keeps a lot of data off the bitcoin network, and reduces requirement to trust in a single signing authority.
1241 2012-08-20 16:13:06 <TD> no need to be a PoW chain, as far as i can tell, if you just want to publish messages
1242 2012-08-20 16:13:14 gfinn has joined
1243 2012-08-20 16:13:28 <jgarzik> heck, require consensus of 7 signing authorities, each validating the bond market rules
1244 2012-08-20 16:13:43 <gavinandresen> tonikt: http://www.boost.org/doc/libs/1_37_0/doc/html/foreach.html says BOOST_REVERSE_FOREACH was in 1.37...
1245 2012-08-20 16:13:45 <TD> though that said, i think the messages needed for bonds/stocks/funds/etc wouldn't be particularly large anyway, so it may be better to just let people pay the higher fees and then rely on pruning to get rid of them eventually
1246 2012-08-20 16:13:47 robocoin has joined
1247 2012-08-20 16:14:28 <jgarzik> TD: if it's successful, I think you want it to be able to scale to do HFT.  signing authorities that bundle transactions together would help mitigate HFT -> bitcoin network resolution.
1248 2012-08-20 16:14:32 <BlueMatt> gavinandresen: re: any txn to test the SIGHASH_SINGLE bug? all I know of is https://github.com/bitcoin/bitcoin/pull/1651
1249 2012-08-20 16:14:34 <jgarzik> distributed resolution authority
1250 2012-08-20 16:14:43 <jgarzik> with real bitcoin money
1251 2012-08-20 16:15:34 <jgarzik> TD: thus, it would be nice to design the system to -not- start out dumping every single transaction involving bitcoins into the blockchain, if there is a better alternative
1252 2012-08-20 16:16:20 * jgarzik wonders if SatoshiDICE could be done with multisig + distributed verifiers, and prevent both cheating and collusion
1253 2012-08-20 16:16:58 <tonikt> gavinandresen: thanks. 0.6.3 builds just fine in my gitian, but the master branch - still working on it
1254 2012-08-20 16:17:04 <gavinandresen> BlueMatt: RE: 1651: I just submitted a pull request for a different way of making unit tests quiet (adding Yet Another fPrintFlag bugged me)
1255 2012-08-20 16:17:22 <BlueMatt> sounds good, Ill remove that
1256 2012-08-20 16:19:07 slush1 has quit (Ping timeout: 244 seconds)
1257 2012-08-20 16:19:58 denisx has quit (Quit: denisx)
1258 2012-08-20 16:20:00 * jgarzik is trying to think generally -- given an application (SD, bond trading) that implies a lot of transactions, is it possible to devise a distributed set of authorities that work together to (a) validate incoming [data | transactions], and (b) bundle together outgoing transactions into network, blockchain friendly packages?  In the far future, I think bitcoin becomes a resolution currency, with activity happening off-network, with settlemen
1259 2012-08-20 16:20:26 <TD> i'm not sure it does imply a lot of transactions, necessarily
1260 2012-08-20 16:20:26 <BlueMatt> jgarzik: your /me looks f'd up to me...
1261 2012-08-20 16:20:40 <BlueMatt> bitcoin.org down for anyone else?
1262 2012-08-20 16:21:03 <TD> but at any rate, the tx replacement mechanism was designed to allow HFT, at least that's how satoshi made it appear to me
1263 2012-08-20 16:21:10 <TD> BlueMatt: works for me
1264 2012-08-20 16:21:25 <jgarzik> BlueMatt: wfm
1265 2012-08-20 16:21:28 <BlueMatt> odd
1266 2012-08-20 16:21:34 <jgarzik> BlueMatt: what's f'd up about it? :)
1267 2012-08-20 16:21:41 <BlueMatt> I see 
1268 2012-08-20 16:21:41 * BlueMatt 
1269 2012-08-20 16:21:56 <BlueMatt> but it looked ok last time
1270 2012-08-20 16:23:09 * gavinandresen sees jgarzik's /me just fine
1271 2012-08-20 16:23:18 <BlueMatt> hmm...guess Im having problems then
1272 2012-08-20 16:23:46 Maged has joined
1273 2012-08-20 16:23:50 <jgarzik> TD: I'm not sure that is applicable to all situations.  Each trade is final, with an audit trail often required by law to reflect such.
1274 2012-08-20 16:24:32 <TD> i think if these markets ever develop to the point where HFT actually happens, we'll be living in a star trek future and whatever crazy computers we're running will be able to keep up with the transaction rate without issue
1275 2012-08-20 16:24:37 <TD> so right now i'm not too worried about it
1276 2012-08-20 16:24:38 ForceMajeure has quit (Ping timeout: 276 seconds)
1277 2012-08-20 16:25:04 <jgarzik> with SatoshiDICE > 50% of the network traffic, I'm already worrying about data services riding on the blockchain
1278 2012-08-20 16:25:12 <jgarzik> and your spec adds one more :)
1279 2012-08-20 16:25:54 Rabbit67890 is now known as RainbowDashh
1280 2012-08-20 16:26:23 <jgarzik> There needs to be a distributed small message data notary service that is not bitcoin :)
1281 2012-08-20 16:26:31 <sunshinehappy> could satoshi dice 51%?
1282 2012-08-20 16:26:38 <BlueMatt> no
1283 2012-08-20 16:26:52 <BlueMatt> different type of 50%
1284 2012-08-20 16:27:04 <sunshinehappy> I heard you could double spend on satoshi dice
1285 2012-08-20 16:27:09 <sunshinehappy> has anyone proved that in practice?
1286 2012-08-20 16:27:11 <amiller> we also need to sort out the fee schedule at some point, i doubt satoshidice provides >50% of fees, especially since we're still in subsidy mode
1287 2012-08-20 16:27:32 <jgarzik> amiller: fee != initial block reward
1288 2012-08-20 16:27:39 olp has quit (Ping timeout: 252 seconds)
1289 2012-08-20 16:27:45 <TD> i wouldn't describe satoshidice as a "data service"
1290 2012-08-20 16:27:48 <jgarzik> amiller: it is conceivable that SD provides >50% of all fees
1291 2012-08-20 16:27:51 <TD> those are real bitcoin transactions that move money around
1292 2012-08-20 16:28:00 <BlueMatt> sunshinehappy: yes, there are theoretical attacks because of the way sd does tx handling, in practice, I haven't seen anything
1293 2012-08-20 16:28:00 <jgarzik> TD: it sends 1 satoshi to notify you of losing bets
1294 2012-08-20 16:28:04 <jgarzik> :(
1295 2012-08-20 16:28:09 <TD> oh, ok
1296 2012-08-20 16:28:20 <TD> those transactions must take forever to confirm
1297 2012-08-20 16:28:44 <TD> i think over time bitcoinj will help people write customized clients for that kind of thing
1298 2012-08-20 16:28:53 <jgarzik> or pynode :)
1299 2012-08-20 16:28:59 <TD> there's no particular reason to use bizarre in-band messaging protocols. it's done that way because modfiying satoshis code is too complicated
1300 2012-08-20 16:29:01 <TD> yes or pynode
1301 2012-08-20 16:29:07 <jgarzik> </plug>
1302 2012-08-20 16:29:08 <jgarzik> :)
1303 2012-08-20 16:29:40 <gavinandresen> mmmm... pie....
1304 2012-08-20 16:31:21 <jgarzik> I'll try to think some more on a distributed stock/bond trading market.  It does seem to me to be doable simply by requiring X "authority agents" to all validate rules, and then sign multisig transactions that transfer bitcoins from Alice to Bob, after agreeing that 100 shares of FOO stock was transferred from Bob to Alice.
1305 2012-08-20 16:31:46 osmosis has joined
1306 2012-08-20 16:32:07 <jgarzik> the impact to the bitcoin blockchain would be fewer, larger transactions settling up with Alice and Bob at the end of the day
1307 2012-08-20 16:32:10 Maged has quit (Ping timeout: 246 seconds)
1308 2012-08-20 16:32:18 <jgarzik> or s/day/$TimePeriod/
1309 2012-08-20 16:32:45 <jgarzik> if Alice and Bob are HFT'ing, that is a _lot_ of intermediate bitcoin transfers back and forth that simply do not appear in the blockchain
1310 2012-08-20 16:33:08 <TD> did you read the post i wrote? you can model a bond transfer as a regular transaction. the client can then calculate whether bond issuers are keeping up with their payments or not by scanning the block chain looking for the payments to the ownership key
1311 2012-08-20 16:33:22 <TD> i didn't need any authority agents in the design posted on the forum
1312 2012-08-20 16:33:32 <TD> (well except for distributed investment funds, but that's different)
1313 2012-08-20 16:33:36 <amiller> sipa, do you have any thoughts about the size of the UTXO-set over time? do you think of it as something that stabilizes to a bounded size, or something that grows linearly with time?
1314 2012-08-20 16:33:55 <jgarzik> TD: yes, that's the tradeoff.  lack of authority agents == much greater blockchain spam.
1315 2012-08-20 16:34:15 <TD> i don't see why. selling a bond to somebody else requires a financial transfer anyway (assuming you actually pay in bitcoins)
1316 2012-08-20 16:34:19 cande has quit (Ping timeout: 265 seconds)
1317 2012-08-20 16:34:19 <Joric> TD, i'm going to write bitcoin j2me app for ancient phones, any advice? :) sold 6 j2me games in the last decade but market seems dead now
1318 2012-08-20 16:34:21 <TD> so all you need is an extra output
1319 2012-08-20 16:34:30 <TD> Joric: er, don't do it? why would you want to do that?
1320 2012-08-20 16:34:44 <TD> Joric: i think a bitbank frontend type app is the only possibility there
1321 2012-08-20 16:35:29 olp has joined
1322 2012-08-20 16:35:37 <jgarzik> TD: see what I just wrote, above.  if some parties are doing a large number of transactions, all those bitcoin transactions could be kept off-network and collated into a few resolution transactions at the end of the day.
1323 2012-08-20 16:36:52 <sipa> amiller: hard to guess
1324 2012-08-20 16:37:29 <TD> then it's not a distributed market though. you may as well just use GLBSE. using miners to enforce the ruleset is how you make it distributed
1325 2012-08-20 16:37:44 <sipa> amiller: if the exchange rate increases, smaller transactions become viable and necessary, so the degree to which amounts are split out over UTXO's would rise
1326 2012-08-20 16:37:56 <Joric> i wonder how much time it would take for sigining a transacion :D those phones are slow as hell
1327 2012-08-20 16:38:10 <jgarzik> TD: it is a distributed market if you require X independent agents to validate and resolve your stock market transactions
1328 2012-08-20 16:38:35 <TD> Joric: don't sign on the phone ....
1329 2012-08-20 16:38:38 <amiller> but the rate at which UTXOs are spent would also rise
1330 2012-08-20 16:39:01 <amiller> would you say the rate of UTXOs spent would match the rate of UTXOs created?
1331 2012-08-20 16:39:18 <sipa> the size of the UTXO set is definitely increasing right now
1332 2012-08-20 16:39:22 <sipa> but not that quickly
1333 2012-08-20 16:39:37 <sipa> i've seen it grow from 70 to 80 MiB in the last 2 months or so
1334 2012-08-20 16:39:51 <jgarzik> TD: create transactions that require X multisig signatures, and then use a known "bond chain" and "bond P2P network" that signing authorities listen on
1335 2012-08-20 16:40:09 <jgarzik> sipa: what is UTXO?
1336 2012-08-20 16:40:37 <TD> i'd rather just scale the core transaction processing to support lots of transactions
1337 2012-08-20 16:40:38 <gavinandresen> unspent transaction output
1338 2012-08-20 16:41:02 <jgarzik> but there is no need to crap up the main chain with this extra data
1339 2012-08-20 16:41:08 <TD> over time i'm getting less enamoured of having separate networks and chains for financially related things. for stuff that's not financial like DNS or SSL certs or whatever, sure
1340 2012-08-20 16:41:35 Motest003 has joined
1341 2012-08-20 16:41:57 <TD> i think over time people will get less sensitive about block chain size and tx rates
1342 2012-08-20 16:42:14 <TD> as the core code gets better. with better db usage, multi-threaded tx verification, sharded/offloaded signature verifications and so on
1343 2012-08-20 16:42:20 <amiller> jgarzik, if it's 200 years in the future and there's no initial block reward, then it makes sense if 50% of the network pays 50% of the fees
1344 2012-08-20 16:42:25 tsche has joined
1345 2012-08-20 16:42:38 <amiller> the initial blockreward is giving satoshidice a free ride
1346 2012-08-20 16:42:47 <jgarzik> even with ultraprune, scaling up to a paypal or Visa level of transactions will ultimately require a lot of bandwidth and data storage, regardless of how prunable the data is.
1347 2012-08-20 16:42:54 Maged has joined
1348 2012-08-20 16:43:06 <jgarzik> designing non-currency-related data applications to piggyback makes the problem worse
1349 2012-08-20 16:43:24 <TD> i need to rewrite the scalability page to take into account the latest developments
1350 2012-08-20 16:43:44 <jgarzik> amiller: agreed
1351 2012-08-20 16:43:46 <TD> i guess i don't see it as a big deal. with the recent improvements and corrections to the numbers on that page it seems like 10ktps is quite achievable by a single studly server
1352 2012-08-20 16:43:55 <TD> and the bandwidth usage isn't a big deal for anything sitting in a datacenter
1353 2012-08-20 16:44:00 danbri has quit (Remote host closed the connection)
1354 2012-08-20 16:44:33 <jgarzik> yes -- it implies at that point that only [a few] studly servers on studly connections are supporting the bitcoin network :)
1355 2012-08-20 16:44:51 <sipa> i think the most important effect of ultraprune is that it allows separation between blockchain-storage/serving and transaction validation
1356 2012-08-20 16:44:54 <gavinandresen> I agree with TD.  And I think "a few" will actually be "hundreds", which is plenty.
1357 2012-08-20 16:45:26 <sipa> storage and bandwidth are cheap, but not what every end-user or even merchant wants to do
1358 2012-08-20 16:45:46 <TD> by "studly server" i mean something like a 24 core machine with a bunch of hard disks attached
1359 2012-08-20 16:45:53 <TD> hardly out of reach even for hobbyists, assuming they have a job
1360 2012-08-20 16:45:56 <TD> and that's with todays tech
1361 2012-08-20 16:46:45 <TD> at any rate
1362 2012-08-20 16:46:57 <TD> i'd rather start with simple designs and evolve them later if the scalability starts to hurt
1363 2012-08-20 16:47:10 <jgarzik> <shrug> oh well.  If you don't discourage blockchain-as-general-messaging and blockchain-as-general-data-storage, that is what it will devolve into.
1364 2012-08-20 16:47:15 <TD> remember that when satoshi was designing bitcoin he thought it was just on the boundary of feasability and thought scalability would be the biggest achilles heel
1365 2012-08-20 16:47:21 <TD> over time it hasn't proven to be such a big deal as he thought
1366 2012-08-20 16:47:42 <TD> i'm not saying use the block chain for things like SDs 1 satoshi messages
1367 2012-08-20 16:47:53 <TD> that's clearly just abusing the broadcast network because they don't have a real client of their own
1368 2012-08-20 16:48:05 <sipa> jgarzik: i think it's a bad thing that our only way of transferring a transaction from sender to receiver, is *via* the blockchain
1369 2012-08-20 16:48:10 <TD> for things like a bond where you want the act of payment to be atomic with transfer of control, it's a natural fit for the block chain
1370 2012-08-20 16:48:17 <sipa> hard to prevent people from seeing it as a communication channel
1371 2012-08-20 16:48:19 <TD> other solutions end up being weird and awkward, or at least a lot more complicated
1372 2012-08-20 16:50:04 <amiller> satoshidice needs to be kept out of the UTXO :/
1373 2012-08-20 16:50:05 <TD> basically for smart property, it makes sense to encode the data into an output because that assures atomicity. now whether it makes sense to encode that data directly as a script chunk, or as a hash that keys into some other data storage mechanism, i don't know
1374 2012-08-20 16:50:10 <amiller> no one's gonna spend that junk
1375 2012-08-20 16:50:24 <TD> i started out by thinking it has to be a hash poiner. now i think it'll matter less
1376 2012-08-20 16:51:12 <BlueMatt> how much of its own utxo has sd spent? if they went and spent all their utxo to one tx, would it make a big difference?
1377 2012-08-20 16:51:36 <amiller> who are those 1 satoshi messages sent _to_?
1378 2012-08-20 16:51:38 <amiller> the loser?
1379 2012-08-20 16:51:43 <BlueMatt> yea
1380 2012-08-20 16:51:44 danbri has joined
1381 2012-08-20 16:51:57 <amiller> so SD can't spent them theirselves, its up to the clients who have no motivation to do so
1382 2012-08-20 16:52:14 <TD> er, a wallet implementation will use whatever coins it has lying around eventually
1383 2012-08-20 16:52:19 <TD> you can't assume they'll never be spent
1384 2012-08-20 16:52:27 danbri has quit (Remote host closed the connection)
1385 2012-08-20 16:52:35 <BlueMatt> amiller: I mean the winings that sd has accumulated from losers
1386 2012-08-20 16:52:51 <BlueMatt> not those sent back to losers/winners
1387 2012-08-20 16:53:00 <amiller> i'm assuming they _might_ never be spent, and that's a problem if it's generally accepted that the UTXO shouldn't grow linearly
1388 2012-08-20 16:53:21 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
1389 2012-08-20 16:58:32 cande has joined
1390 2012-08-20 16:59:20 imsaguy2 is now known as [\\\]
1391 2012-08-20 16:59:38 bakh_ has joined
1392 2012-08-20 17:00:14 [\\\] is now known as imsaguy2
1393 2012-08-20 17:00:27 ForceMajeure has joined
1394 2012-08-20 17:00:42 genjix_afk is now known as genjix
1395 2012-08-20 17:02:51 bakh has quit (Ping timeout: 252 seconds)
1396 2012-08-20 17:04:30 <gavinandresen> RE: unspent satoshi outputs:  for 0.8 I want to tweak the coin selection and fee code. Assuming miners adopt the sort-by-fee changes in 0.7, we should be able to get rid of the "single satoshi outputs cost MIN_FEE to spend" rule, and make the coin selection code include a couple of small inputs to minimize UTXO
1397 2012-08-20 17:06:21 <gmaxwell> They don't cost minfee to spend, they cost minfee to create.
1398 2012-08-20 17:06:51 <gmaxwell> The 'problem' now is that adding additoinal inputs for pure txout sweeping purposes lowers your priority. Cleaning up the chain is against your interest.
1399 2012-08-20 17:07:33 PhantomSpark has quit (2!~kvirc@pool-71-251-16-25.nycmny.fios.verizon.net|Ping timeout: 246 seconds)
1400 2012-08-20 17:07:44 <gmaxwell> (they lower your priority because they make the txn smaller)
1401 2012-08-20 17:07:46 <gavinandresen> Right, the client code would do something like "add a tiny input if it won't hurt your priority/fee"
1402 2012-08-20 17:08:12 <gavinandresen> (or won't hurt it enough to significantly change chances of getting into next block)
1403 2012-08-20 17:08:37 <gavinandresen> I'm still planning on writing code to estimate how long it will take a given transaction to get into a block.....
1404 2012-08-20 17:08:58 <jgarzik> note if you need extra data validation for your OP_DROP data, that's a required authority (since bitcoin is not validating your rules)
1405 2012-08-20 17:09:05 <amiller> gmaxwell, you should say cleaning up the UTXO rather than cleaning up the chain, since there's no way to clean the chain (it's append only)
1406 2012-08-20 17:09:08 <TD> one thing i've wanted to do for a while (but won't get to for ages) is write background cleaning/aggregation code for bitcoinj, so the android wallet can consolidate outputs at night time when the user is asleep
1407 2012-08-20 17:09:12 <gmaxwell> right, someplace I have code for this — but when I used it it caused all the addresses in my wallet to get linked right away, the loss of privacy seemed bad.
1408 2012-08-20 17:09:42 <TD> jgarzik: the data that's dropped, at least in my designs, is validated by each users client rather than some kind of authority.
1409 2012-08-20 17:09:47 <gmaxwell> TD: "Meh" I don't like that— it should do most of that in actual transactions.
1410 2012-08-20 17:09:51 BitByBit has joined
1411 2012-08-20 17:11:38 denisx has joined
1412 2012-08-20 17:12:06 <gavinandresen> gmaxwell: privacy concern is a good point... although I think users with lots of tiny transactions in their wallets might not care.
1413 2012-08-20 17:12:44 Guest15691 is now known as bdcs
1414 2012-08-20 17:12:45 <gmaxwell> gavinandresen: my hope was that this address group code would solve it. (only pull in things with the already linked groups).  But now after actually working with the code, I don't like it.
1415 2012-08-20 17:12:50 <sipa> trying to add small inputs as long as it's harmless may help a bit, but a more final solution should effectively increase priority or lower cost, when it consumes many txins
1416 2012-08-20 17:12:50 bdcs has quit (Changing host)
1417 2012-08-20 17:12:50 bdcs has joined
1418 2012-08-20 17:13:15 <gmaxwell> A short term improvement would be to only add inputs which are from the same addresses as the inputs that are already there.
1419 2012-08-20 17:13:23 <gmaxwell> It's not very general but it would work very well with the dice spam.
1420 2012-08-20 17:13:33 <gmaxwell> And it's both privacy safe and computationally cheap.
1421 2012-08-20 17:13:48 sunshine_ has joined
1422 2012-08-20 17:15:15 <gmaxwell> e.g. iff there is spare fee/priority AND there is already a change output, collect a list of other outputs to the inputs the txn used, sort by value least to most, and add the least value one one at a time until there is no more "free" space.
1423 2012-08-20 17:15:59 sunshinehappy has quit (Ping timeout: 276 seconds)
1424 2012-08-20 17:17:59 RainbowDashh has quit (Ping timeout: 244 seconds)
1425 2012-08-20 17:19:41 dust-otc has quit (Remote host closed the connection)
1426 2012-08-20 17:23:32 <Joric> next difficulty estimate +11%
1427 2012-08-20 17:24:02 <Joric> 4 days left
1428 2012-08-20 17:25:10 <TD> if pubsub was activated the network could be used to find people who also wanted to combine their wallets
1429 2012-08-20 17:25:18 <TD> and then a shared transaction would merge and split across multiple peers
1430 2012-08-20 17:25:24 <TD> effectively an automatic p2p mixing service
1431 2012-08-20 17:25:41 RainbowDashh has joined
1432 2012-08-20 17:25:44 RainbowDashh has quit (Changing host)
1433 2012-08-20 17:25:44 RainbowDashh has joined
1434 2012-08-20 17:29:00 BitByBit has quit (Read error: Connection reset by peer)
1435 2012-08-20 17:29:12 <gmaxwell> TD: meh, thats not actually useful without an anonymity network in between.
1436 2012-08-20 17:29:14 <gavinandresen> TD: somebody could use the raw transactions API to create such a service
1437 2012-08-20 17:29:22 BitByBit has joined
1438 2012-08-20 17:29:29 <gavinandresen> (run through tor maybe....)
1439 2012-08-20 17:29:33 <gmaxwell> gavinandresen: it still needs the ability to put pending outputs on hold. :)
1440 2012-08-20 17:30:04 <gavinandresen> gmaxwell: true, locking unspent outputs should get implemented.
1441 2012-08-20 17:30:05 BitByBit has quit (Read error: Connection reset by peer)
1442 2012-08-20 17:30:16 BitByBit has joined
1443 2012-08-20 17:30:31 <TD> ?
1444 2012-08-20 17:31:39 <gavinandresen> when you're in the middle of gathering signatures for an anonymizing send-to-selves transaction there's nothing currently stopping somebody from creating another transaction (using the GUI maybe) that accidently double-spends some of the inputs involved
1445 2012-08-20 17:32:09 Maged has joined
1446 2012-08-20 17:35:04 <genjix> TD: why would mix and matching help scalability in any significant way? from what i understand, the spends and outputs would remain the same except there would be fewer transactions now.
1447 2012-08-20 17:36:57 <TD> gavinandresen: yes, but does it matter? if that happens you restart the protocol
1448 2012-08-20 17:37:05 <TD> genjix: because it'd shrink the working set
1449 2012-08-20 17:37:05 tonikt has quit (Read error: Connection reset by peer)
1450 2012-08-20 17:37:58 <genjix> but that's hardly a bottleneck currently.
1451 2012-08-20 17:38:13 <genjix> unless i'm missing something?
1452 2012-08-20 17:38:27 <TD> we're thinking long term
1453 2012-08-20 17:38:28 <gavinandresen> TD: I think you're right, it shouldn't matter. The protocol will have to handle double-spends to be robust anyway.
1454 2012-08-20 17:38:28 * TD -> home
1455 2012-08-20 17:38:33 TD has quit (Quit: TD)
1456 2012-08-20 17:38:33 <genjix> ah ok
1457 2012-08-20 17:39:21 tonikt has joined
1458 2012-08-20 17:40:20 da2ce7_d has joined
1459 2012-08-20 17:41:33 BitByBit has quit (Read error: Connection reset by peer)
1460 2012-08-20 17:41:42 BitByBit has joined
1461 2012-08-20 17:41:59 da2ce7 has quit (Ping timeout: 276 seconds)
1462 2012-08-20 17:42:10 AlexWaters has quit (Remote host closed the connection)
1463 2012-08-20 17:45:11 ForceMajeure_ has joined
1464 2012-08-20 17:45:17 asa has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- Chicks dig it)
1465 2012-08-20 17:46:45 Karmaon1 has joined
1466 2012-08-20 17:47:02 ForceMajeure has quit (Ping timeout: 240 seconds)
1467 2012-08-20 17:48:37 ForceMajeure_ is now known as ForceMajeure
1468 2012-08-20 17:48:44 sunshine_ is now known as sunshinehappy
1469 2012-08-20 17:49:57 BitByBit has quit (Read error: Connection reset by peer)
1470 2012-08-20 17:50:13 BitByBit79 has joined
1471 2012-08-20 17:51:09 BitByBit79 has quit (Read error: Connection reset by peer)
1472 2012-08-20 17:52:06 BitByBit79 has joined
1473 2012-08-20 17:53:03 BitByBit79 has quit (Read error: Connection reset by peer)
1474 2012-08-20 17:53:08 MC-Eeepc has quit (Ping timeout: 244 seconds)
1475 2012-08-20 17:53:13 BitByBit79 has joined
1476 2012-08-20 17:53:41 MC-Eeepc has joined
1477 2012-08-20 17:53:56 <gmaxwell> sipa: https://github.com/bitcoin/bitcoin/pull/1672 Is that what you wanted me to do wrt the wallet class?
1478 2012-08-20 17:54:21 BitByBit79 has quit (Read error: Connection reset by peer)
1479 2012-08-20 17:54:36 BitByBit79 has joined
1480 2012-08-20 17:54:42 DiabloD3 has quit (Remote host closed the connection)
1481 2012-08-20 17:56:02 BitByBit79 has quit (Read error: Connection reset by peer)
1482 2012-08-20 17:56:15 BitByBit79 has joined
1483 2012-08-20 17:59:36 Diablo-D3 has joined
1484 2012-08-20 18:02:47 B0g4r7 has quit (Ping timeout: 276 seconds)
1485 2012-08-20 18:02:58 RainbowDashh has quit (Ping timeout: 256 seconds)
1486 2012-08-20 18:03:18 <Joric> can transaction without outputs be considered valid? like, a fee-only transaction
1487 2012-08-20 18:05:00 <bdcs> Yes
1488 2012-08-20 18:05:16 <bdcs> It's called "coin melting" colloquially
1489 2012-08-20 18:05:34 <bdcs> as a means to anonymize bitcoins
1490 2012-08-20 18:06:00 <bdcs> Just make sure a different miner doesn't get the txn : )
1491 2012-08-20 18:06:14 <genjix> risky
1492 2012-08-20 18:06:18 <gavinandresen> Transactions must have at least one output. But zero-value outputs are legal.
1493 2012-08-20 18:06:33 <gmaxwell> gavinandresen: don't encourage them!
1494 2012-08-20 18:06:34 <gmaxwell> :)
1495 2012-08-20 18:06:45 * bdcs stands corrected
1496 2012-08-20 18:07:57 <bdcs> gmaxwell, I'm curious, do you have qualms with "coin melting?"
1497 2012-08-20 18:08:03 RainbowDashh has joined
1498 2012-08-20 18:08:21 <gmaxwell> bdcs: no, though its silly. I have qualms with encouraging people to create zero value txouts. :)
1499 2012-08-20 18:08:36 <Joric> so, if i got it right, satoshi client won't relay those?
1500 2012-08-20 18:09:07 <gmaxwell> bdcs: It's a poor anonymization technique, because it requires miner cooperation and once someone is available they can identify it it with fairly high probablity.
1501 2012-08-20 18:09:12 <ThomasV> gmaxwell: it is not worse than satoshidice...
1502 2012-08-20 18:09:32 <midnightmagic> not only miner cooperation, but you risk losing it entirely
1503 2012-08-20 18:10:17 <gmaxwell> ThomasV: well there is no incentive to ever spend a zero value output, so they possibly create unbounded txout bloat. IMO they should have been prohibited by the protocol.
1504 2012-08-20 18:10:34 <gmaxwell> Not that 1e-8 is much better.
1505 2012-08-20 18:11:20 <bdcs> in the case of coinmelting, the same dummy address could be used, no? (obviously at cost of announcing, I'M COIN MELTING!)
1506 2012-08-20 18:11:44 <gmaxwell> bdcs: once its announced its totally pointless. And likewise, using atypical fee amounts for it also makes it pointless.
1507 2012-08-20 18:12:47 <bdcs> Fair enough, you certainly know better than I do; I'm simply enamored with the name "coin melting!" : )
1508 2012-08-20 18:12:59 <gmaxwell> hah.
1509 2012-08-20 18:13:16 <gmaxwell> Joint input transactions are a much better anonymization technique.
1510 2012-08-20 18:13:58 <Luke-Jr> gmaxwell: would be better to prohibit spendable 0-outputs imo
1511 2012-08-20 18:14:10 <bdcs> From what I know, I agree
1512 2012-08-20 18:14:17 <Luke-Jr> gmaxwell: so long as the 0-output is unspendable (scriptPubKey[0] == OP_RETURN), it can be safely ignored
1513 2012-08-20 18:15:03 <Joric> does anyone know for sure will reference client relay transaction without outputs?
1514 2012-08-20 18:15:28 <Luke-Jr> Joric: it won't. they're invalid.
1515 2012-08-20 18:15:29 <gmaxwell> Luke-Jr: so, no, well, we're going to be @#$#@ed on that soon.
1516 2012-08-20 18:15:33 <Luke-Jr> gmaxwell: ?
1517 2012-08-20 18:15:55 <gmaxwell> Luke-Jr: because you can't ignore txouts if they're required to be in tree committments.
1518 2012-08-20 18:16:22 <jgarzik> BFL asks:  ship a small quantity first and larger one later, or wait and ship an even larger order all at once: https://bitcointalk.org/index.php?topic=87934.msg1109145#msg1109145
1519 2012-08-20 18:16:25 <Luke-Jr> so whoever implements tree committments needs to be aware of explicitly unspendable outputs..
1520 2012-08-20 18:17:20 <gmaxwell> Luke-Jr: Right, if they are to be excluded the definition of unspendable becomes normative.
1521 2012-08-20 18:17:45 BitByBit79 has quit (Read error: Connection reset by peer)
1522 2012-08-20 18:18:00 BitByBit79 has joined
1523 2012-08-20 18:18:23 Maged has quit (Ping timeout: 276 seconds)
1524 2012-08-20 18:19:12 ThomasV has quit (Quit: Leaving)
1525 2012-08-20 18:19:36 molecular has quit (Ping timeout: 246 seconds)
1526 2012-08-20 18:20:37 molecular has joined
1527 2012-08-20 18:22:00 <gavinandresen> Looking for ACKs on https://github.com/bitcoin/bitcoin/pull/1687 and https://github.com/bitcoin/bitcoin/pull/1689  -- I think both aught to be pre-0.7rc1
1528 2012-08-20 18:22:47 <gmaxwell> gavinandresen: testing 1689 now.
1529 2012-08-20 18:23:07 <sunshinehappy> excuse me
1530 2012-08-20 18:23:10 <sunshinehappy> I was just banned #bitcoin
1531 2012-08-20 18:23:12 <sunshinehappy> but I wasn't even talking
1532 2012-08-20 18:23:17 <sunshinehappy> everyone else was using my name
1533 2012-08-20 18:23:44 <sunshinehappy> please help
1534 2012-08-20 18:23:50 <gmaxwell> sunshinehappy: this is not #complain-about-#bitcoin this is a channel for technical discussion.
1535 2012-08-20 18:23:58 <sunshinehappy> gmaxwell, please help me
1536 2012-08-20 18:24:40 BitByBit79 has quit (Read error: Connection reset by peer)
1537 2012-08-20 18:25:00 user__ has quit (Quit: Leaving)
1538 2012-08-20 18:26:24 <sunshinehappy> please
1539 2012-08-20 18:26:59 user has joined
1540 2012-08-20 18:28:10 BitByBit79 has joined
1541 2012-08-20 18:28:11 user has quit (Client Quit)
1542 2012-08-20 18:28:32 user has joined
1543 2012-08-20 18:31:36 <gmaxwell> Cure my RPC stupid, how the hell can I send a sighashtype argument to signrawtransaction without the inputs and private key arguments?
1544 2012-08-20 18:31:53 <gmaxwell> (sending empty sets for them isn't doing what I want)
1545 2012-08-20 18:33:15 <gavinandresen> gmaxwell: you can give '[]' as inputs, but you'll need to dig out the private keys using dumpprivkey for the private key arg....
1546 2012-08-20 18:33:43 tower has quit (Remote host closed the connection)
1547 2012-08-20 18:33:45 <gavinandresen> gmaxwell: I waffled on whether an empty array for private keys should mean "don't sign anything" or "lookup private keys in the wallet"
1548 2012-08-20 18:33:46 <gmaxwell> yea, thats ... bleh.
1549 2012-08-20 18:34:05 <gmaxwell> gavinandresen: whats the harm in lookup private keys? it can always fail.
1550 2012-08-20 18:34:11 <gavinandresen> "don't sign anything" is actually useful for just figuring out if a raw transaction is complete.
1551 2012-08-20 18:34:12 <sunshinehappy> yeah I'm not interested in this shit
1552 2012-08-20 18:34:47 <gmaxwell> gavinandresen: I use decoderawtransaction for that.
1553 2012-08-20 18:34:53 <gmaxwell> though it doesn't give a handy flag.
1554 2012-08-20 18:35:04 <gavinandresen> decoderawtransaction doesn't actually check the signatures, though.
1555 2012-08-20 18:35:13 tower has joined
1556 2012-08-20 18:35:19 <gmaxwell> gavinandresen: making people extract (and thus handle) private keys to set the sighash type is cruddy.
1557 2012-08-20 18:35:33 <gmaxwell> perhaps we should change the argument order? (since adding "ALL" isn't so hard)
1558 2012-08-20 18:35:43 D34TH has joined
1559 2012-08-20 18:35:43 <gavinandresen> mmm.   I wonder if we can pass 'null' and check for it....
1560 2012-08-20 18:36:06 <gmaxwell> how about a "NONE" sighash type? :)
1561 2012-08-20 18:36:10 BitByBit79 has quit (Remote host closed the connection)
1562 2012-08-20 18:36:10 <gmaxwell> e.g. don't sign?
1563 2012-08-20 18:36:29 <gavinandresen> there's already a NONE
1564 2012-08-20 18:36:40 <gmaxwell> er, right. Um. NULL. hah
1565 2012-08-20 18:37:40 <gavinandresen> The issue with "always look in the wallet for keys" is that means you'd always have to unlock a locked wallet before calling signrawtransaction
1566 2012-08-20 18:38:05 <gavinandresen> ... even if you're providing all the private keys...
1567 2012-08-20 18:38:28 CluckCreek has joined
1568 2012-08-20 18:38:53 <gavinandresen> The bets fix would probably be to teach the RPC code to handle named (instead of positional) params
1569 2012-08-20 18:38:57 tower has quit (Changing host)
1570 2012-08-20 18:38:57 tower has joined
1571 2012-08-20 18:39:00 <gavinandresen> ^best
1572 2012-08-20 18:39:17 <gmaxwell> gavinandresen: hm, Tou can tell if you have the keys even if the wallet is locked.
1573 2012-08-20 18:39:20 user is now known as TRefgh
1574 2012-08-20 18:39:24 <gmaxwell> s/Tou/You/
1575 2012-08-20 18:41:09 TD has joined
1576 2012-08-20 18:42:53 <gmaxwell> gavinandresen: in any case, I'm strongly of the view that we shouldn't force the caller to handle private keys which are in the wallet (the ability to provide external keys is a good one— we just shouldn't force it), I don't really care how we avoid it though.
1577 2012-08-20 18:44:19 <gavinandresen> gmaxwell: I'm assuming that if you're using the non-default SIGHASH_ types you're also almost certainly going to be handling keys yourself.  But maybe that's wrong.
1578 2012-08-20 18:45:45 <gavinandresen> JSON does have null as a first-class type, so passing null as the private-key argument might work nicely
1579 2012-08-20 18:50:57 <gmaxwell> gavinandresen: I don't think thats the case at all.. e.g. you might pass around any a transaction for multisigning with ANYCANPAY among multiple people. The privkeys will never leave their wallets. There are cases where the private keys are external, but we shouldn't force it.
1580 2012-08-20 18:52:11 <gavinandresen> gmaxwell: OK.  I'm teaching signrawtransaction to allow null for the private keys, which will be the same as not specifying that param (which means "lookup in wallet")
1581 2012-08-20 18:52:56 <gmaxwell> Great.
1582 2012-08-20 18:53:10 <gavinandresen> If private keys are given, then I think it is important to ONLY use those, given keys and not automatically lookup any missing from the wallet.  At the very least, that's important for testing.
1583 2012-08-20 18:54:20 <gmaxwell> I'm fine with that. None of this API is especially discoverable. I still struggle some with just getting the json quoting and obj/array distinctions right when I use it. ... just so long as the functionality is there.
1584 2012-08-20 18:55:16 <gmaxwell> BlueMatt: as the reporter of the underlying bug, your ACK on https://github.com/bitcoin/bitcoin/pull/1689 is desirable.
1585 2012-08-20 18:55:18 <Luke-Jr> gavinandresen: why would one use bitcoind *at all* if they have the transaction and keys? o.o
1586 2012-08-20 18:55:42 <Luke-Jr> I mean, it's not like bitcoind's interfaces is especially user-friendly here…
1587 2012-08-20 18:55:44 <gmaxwell> Luke-Jr: because no one has written a standalone signing tool yet.
1588 2012-08-20 18:56:03 <Luke-Jr> gmaxwell: but that's not really much harder than these RPC calls, is it?
1589 2012-08-20 18:56:19 <jgarzik> gmaxwell: imagine a command line interface, and I'll do one in python real quick
1590 2012-08-20 18:56:20 <gmaxwell> Luke-Jr: Well, getting all the decoding and displaying stuff is a fair amount of code.
1591 2012-08-20 18:56:27 <Luke-Jr> hmm
1592 2012-08-20 18:56:43 <Luke-Jr> just seems more like a library thing than RPC to me
1593 2012-08-20 18:57:00 <jgarzik> people use openssl(1) frequently
1594 2012-08-20 18:57:32 <gmaxwell> It is— but thats really a lot of the design of the raw transaction API... it's half a RPC accessed library for external tools, half a power user interface.
1595 2012-08-20 18:58:27 <Luke-Jr> i c
1596 2012-08-20 18:59:21 danbri has joined
1597 2012-08-20 18:59:31 <gmaxwell> Luke-Jr: have you seen my walkthroughs on escrow and offline wallet using the api?  They're ... cluster@#$@#s. It's not easy to use.
1598 2012-08-20 18:59:41 <gmaxwell> But— it makes a lot possible.
1599 2012-08-20 19:00:05 <gmaxwell> though it'll be interesting to see the first wave of wallet stealer apps disguised as rawtxn api tools.
1600 2012-08-20 19:00:30 <Luke-Jr> gmaxwell: I did, but I didn't have the time to figure out how it all works yet.
1601 2012-08-20 19:00:41 <jgarzik> gmaxwell: getblock, getrawtransaction, sendrawtransaction, getrawmempool == external wallet
1602 2012-08-20 19:00:45 <gavinandresen> gmaxwell: FYI: I debugged/tested 1689 by creating a 2-input 1-output testnet send-to-self, extracting the two private keys, then calling signrawtransaction with first SINGLE and both keys (verified: complete:false, only first input signed) and then ALL with just the second key (verified: complete: true, both inputs signed)
1603 2012-08-20 19:01:00 <jgarzik> gmaxwell: no need for local wallet at all, for that use case
1604 2012-08-20 19:01:01 <Luke-Jr> probably should wait until I do before I say anything else stupid on it ;p
1605 2012-08-20 19:01:24 <gmaxwell> gavinandresen: oh thats what I did too. Also tried the passing case. (number of inputs == outputs)
1606 2012-08-20 19:02:20 <gmaxwell> jgarzik: well, almost. I mean, e.g. tracking which inputs are confirmed when there are potential reorgs and such... is a little tricky.
1607 2012-08-20 19:02:45 <gmaxwell> it would be interesting to see armory redone using this API and all the block handling stuff removed.
1608 2012-08-20 19:04:08 <gmaxwell> (also, electrum. have you guys looked into seeing how it works? The server for it has the blockchain protocol basically implemented in SQL)
1609 2012-08-20 19:04:10 <jgarzik> gmaxwell: it's not as tricky as a full client.  you'd know you are either on the main chain, as your upstream believes it to be, or on a garbage side chain you may stop tracking.  anything with less than X confirms becomes zero-conf and needs resending.
1610 2012-08-20 19:04:53 <gmaxwell> jgarzik: right but there is no event notfication. so, e.g. finding out a txn you know and care about fell out of the chain takes constant polling.
1611 2012-08-20 19:05:27 <jgarzik> gmaxwell: with "constant" being every 10 minutes or so, i.e. polling you would be doing anyway
1612 2012-08-20 19:06:56 <gmaxwell> A longpollish 'the chain has changed' call would probably help that a lot.
1613 2012-08-20 19:07:17 <gavinandresen> gmaxwell: we can call it -blocknotify
1614 2012-08-20 19:07:33 <gmaxwell> gavinandresen: yea, but that doesn't quite integrate with a RPC caller!
1615 2012-08-20 19:08:28 <jgarzik> as I mentioned in luke-jr pull req, longpoll quite neatly solves the server-to-client async event without requiring an http callback or additional auth code in bitcoin.
1616 2012-08-20 19:09:10 <jgarzik> makes http purists puke of course
1617 2012-08-20 19:09:25 <gavinandresen> longpoll is maintain a set of JSON-RPC-HTTP connections?  (he says, not afraid to show his ignorance of ancient mining pool stuff)
1618 2012-08-20 19:09:27 <jgarzik> longpoll is also firewall friendly
1619 2012-08-20 19:09:33 <Luke-Jr> shrug, it's used for AJAX so can't be too bad :p
1620 2012-08-20 19:09:50 <jgarzik> gavinandresen: you send an HTTP request... and then wait, possibly hours or days etc., for a response
1621 2012-08-20 19:09:54 <Luke-Jr> gavinandresen: basically the server just doesn't reply to the request until something happens
1622 2012-08-20 19:10:04 <jgarzik> gavinandresen: in this case, you send an HTTP request, and does not respond until a new block arrives
1623 2012-08-20 19:10:08 <gmaxwell> It's quite horriffic, but works fine.
1624 2012-08-20 19:10:10 <jgarzik> *do
1625 2012-08-20 19:10:36 <gavinandresen> Don't you run into an open-file-descriptor limit quick on some platforms if you do that?
1626 2012-08-20 19:10:48 <gmaxwell> For something like "your wallet talks to the chain back end" it fits fine... for public mining pools its a bit lame, ... thousnads of concurrent connections to wake all at once..
1627 2012-08-20 19:11:22 <Luke-Jr> gavinandresen: if you have a lot of them
1628 2012-08-20 19:11:50 <Luke-Jr> gmaxwell: eh, you have to wake them all at the same time no matter how you do it..
1629 2012-08-20 19:12:42 <gavinandresen> HTTP-JSON-RPC is designed for that type of thing (long-running request/...wait.../response )
1630 2012-08-20 19:12:49 <gavinandresen> Well, JSON-RPC is....
1631 2012-08-20 19:13:13 <jgarzik> gavinandresen: yeah it's within the protocol... just unexpected and so a lot of libs may time out by default
1632 2012-08-20 19:13:22 tonikt has quit (Read error: Connection reset by peer)
1633 2012-08-20 19:13:22 Clipse has quit (Read error: Connection reset by peer)
1634 2012-08-20 19:13:22 mologie_ has joined
1635 2012-08-20 19:13:23 justmoon has joined
1636 2012-08-20 19:13:29 tonikt has joined
1637 2012-08-20 19:14:07 <gavinandresen> well, then don't use "a lot of libs"
1638 2012-08-20 19:14:47 <jgarzik> just use python-bitcoinrpc ;)
1639 2012-08-20 19:15:20 * gavinandresen goes to look at the keepalive support in bitcoinrpc....
1640 2012-08-20 19:15:31 danbri has quit (Remote host closed the connection)
1641 2012-08-20 19:16:09 <amiller> sipa, question about ultraprune - when you validate a transaction, you look up each input in the [txid->coins] map, then you fetch the entire transaction corresponding to txid?
1642 2012-08-20 19:16:09 mologie- has joined
1643 2012-08-20 19:16:54 mologie has quit (Ping timeout: 276 seconds)
1644 2012-08-20 19:16:54 mologie- is now known as mologie
1645 2012-08-20 19:16:58 <amiller> would it be more efficient if you only had to fetch the relevant scriptpubkey for that UTXO, rather than the whole transaction
1646 2012-08-20 19:17:13 <amiller> hrm, maybe that's what coins.dat is
1647 2012-08-20 19:17:47 <jgarzik> odd
1648 2012-08-20 19:18:01 <jgarzik> why does blockToJSON() look at blockindex for it's previous block?
1649 2012-08-20 19:18:08 <jgarzik> it's right there in CBlock
1650 2012-08-20 19:18:32 <gavinandresen> jgarzik: brain fart, probably
1651 2012-08-20 19:19:04 <jgarzik> ok just checking :)  implementing 'getblock' in pynode
1652 2012-08-20 19:19:28 PhantomSpark has joined
1653 2012-08-20 19:20:08 mologie_ has quit (Ping timeout: 276 seconds)
1654 2012-08-20 19:21:06 <justmoon> amiller: ultraprune only fetches the unspent outputs for the transaction and those are also heavily compressed
1655 2012-08-20 19:21:32 <amiller> merkleizing that would be a little bit harder
1656 2012-08-20 19:22:07 <amiller> in my current thread i guess i'm assuming that you'd have to hash the whole transaction over again just to validate one unspent input
1657 2012-08-20 19:22:10 <BlueMatt> TD: if you get a chance, ignoring a few TODOs, the satoshi bloom-filter+light-block-relay+filtered-block branch has grown a bit... https://github.com/TheBlueMatt/bitcoin/commits/bloom
1658 2012-08-20 19:23:26 <amiller> if i modified the protocol so that keys were of the form (txid,index), and values were of the form (hash of scriptpubkey) then it would be more efficient
1659 2012-08-20 19:24:00 <TD> will review when i get a chance, thanks
1660 2012-08-20 19:26:22 <justmoon> amiller: keep in mind that you do need a few things other than the scriptPubkey - you need isCoinbase and height in block chain for maturity rules and you need the amount
1661 2012-08-20 19:27:04 <amiller> good point
1662 2012-08-20 19:28:00 <BlueMatt> TD: afaik there is only one case where tx hash is duplicated - when the tx is the last in a block with an uneven number of txn
1663 2012-08-20 19:28:12 <BlueMatt> Id say thats rare enough to not care about special-casing
1664 2012-08-20 19:28:36 <Joric> whoa, blockchain.info, blockexplorer and decoderawtransaction produce totally different json, so there are 3 versions already, niice
1665 2012-08-20 19:29:25 <BlueMatt> meh, just use decoderawtransaction
1666 2012-08-20 19:29:39 <justmoon> Joric: I wonder if one of those matches the output that gettransactionbyhash (not sure if that even exists still) had
1667 2012-08-20 19:30:06 <justmoon> (might be misremembering the name)
1668 2012-08-20 19:30:34 <justmoon> (but there was some API call on someone's custom branch that returned a tx in json, that's the format I used for bitcoinjs)
1669 2012-08-20 19:30:39 RainbowDashh has quit (Quit: Computer has gone to sleep.)
1670 2012-08-20 19:31:04 <BlueMatt> you mean the getblock patch that bbe uses?
1671 2012-08-20 19:31:29 <justmoon> hmm, no, it returned a single transaction, would have been mid-2011-ish
1672 2012-08-20 19:31:48 <Joric> there are too many competing standards, we need to develop our universal standard that covers everyone's use cases )
1673 2012-08-20 19:32:09 <justmoon> Joric: there is a xkcd comic about that :D
1674 2012-08-20 19:32:10 <BlueMatt> welcome to the world of open source ;)
1675 2012-08-20 19:32:18 <BlueMatt> well, that too
1676 2012-08-20 19:32:25 <justmoon> http://xkcd.com/927/
1677 2012-08-20 19:32:25 <Joric> yeah i just remembered it
1678 2012-08-20 19:33:33 <amiller> jurov|away, why is "isCoinbase" needed to validate an input?
1679 2012-08-20 19:34:12 <amiller> oh those things are probably relevant for priority calculation
1680 2012-08-20 19:34:14 <Joric> justmoon, gettransactionbyhash doesn't look like any of those 3 either
1681 2012-08-20 19:34:19 <amiller> and therefore minimum fee calculation
1682 2012-08-20 19:34:34 datagutt has quit (Quit: kthxbai)
1683 2012-08-20 19:34:35 <amiller> is that a complete set of what's required from a tx?
1684 2012-08-20 19:35:26 <justmoon> Joric: not surprised, I'll probably wait a bit and then migrate to whatever is the most common, presumably decoderawtransaction, at the next major revision
1685 2012-08-20 19:35:56 <lianj> right now blockexplorer looks most common
1686 2012-08-20 19:36:42 JStoker has quit (Excess Flood)
1687 2012-08-20 19:36:45 <Joric> lianj, using reference client's output seems more logical to me
1688 2012-08-20 19:37:07 <lianj> true, it just hasnt been out that long
1689 2012-08-20 19:37:11 <justmoon> amiller: isCoinbase is necessary because coinbases need to mature before they can be spent - not sure if there are any other reasons
1690 2012-08-20 19:37:42 iocor has quit (Quit: Computer has gone to sleep.)
1691 2012-08-20 19:38:57 <BlueMatt> jgarzik: what happened to your patch that relayed txes that were in blocks?
1692 2012-08-20 19:40:00 Ukto has left ()
1693 2012-08-20 19:40:23 <jgarzik> BlueMatt: not sure what you're talking about
1694 2012-08-20 19:40:28 Clipse has joined
1695 2012-08-20 19:40:38 <BlueMatt> hmm...somehow i thought you had a patch that did that
1696 2012-08-20 19:40:48 <jgarzik> justmoon: there are several special cases related to coinbases
1697 2012-08-20 19:40:59 tonikt has quit (Read error: Connection reset by peer)
1698 2012-08-20 19:41:37 <jgarzik> little details like "during reorg, do not add coinbase TX's to memory pool"
1699 2012-08-20 19:44:01 <jgarzik> gavinandresen gmaxwell: pull tester and everybody else seems happy with #1526 (height in coinbase)... let's pull?
1700 2012-08-20 19:44:06 <jgarzik> sipa: ^
1701 2012-08-20 19:44:41 <gavinandresen> jgarzik: ACK
1702 2012-08-20 19:47:37 <justmoon> regarding the SIGHASH_SINGLE bug, for bitcoinjs to verify transactions correctly, do I need to make sure that my code correctly replicates the bug?
1703 2012-08-20 19:48:08 <BlueMatt> yes
1704 2012-08-20 19:48:35 <justmoon> ok, I'll have a look at it asap
1705 2012-08-20 19:48:49 <justmoon> is there are test case for it?
1706 2012-08-20 19:48:52 <justmoon> a*
1707 2012-08-20 19:49:16 <BlueMatt> see the tx test-cases at https://github.com/bitcoin/bitcoin/pull/1651
1708 2012-08-20 19:49:28 <justmoon> many thanks
1709 2012-08-20 19:49:48 <gavinandresen> "we" should put a test-case in the testnet chain...
1710 2012-08-20 19:52:07 sirk390 has joined
1711 2012-08-20 19:52:11 <jgarzik> getblock, getrawtransaction, getrawmempool: check
1712 2012-08-20 19:52:15 <BlueMatt> meh, any full-implementation needs to be running the data-driven test cases anyway
1713 2012-08-20 19:52:17 <jgarzik> time for sendrawtransaction in pynode
1714 2012-08-20 19:53:06 <justmoon> BlueMatt: I'm running the script ones, hadn't seen these yet
1715 2012-08-20 19:53:23 <BlueMatt> justmoon: well they haven't been merged yet, so...cant say I really blame you
1716 2012-08-20 19:53:31 <justmoon> ^^ <3
1717 2012-08-20 19:53:49 * justmoon is doing his best!
1718 2012-08-20 19:54:29 tsche has quit ()
1719 2012-08-20 19:54:44 rdponticelli has quit (Ping timeout: 260 seconds)
1720 2012-08-20 19:55:17 graingert has joined
1721 2012-08-20 19:55:35 <BlueMatt> gavinandresen: if I start running my block-chain-tester (which throws a test-chain at a random p2p node) on jenkins, should I mention that somewhere other than the comment pull-tester provides?
1722 2012-08-20 19:56:23 <gavinandresen> BlueMatt: uhhh....
1723 2012-08-20 19:56:53 RainbowDashh has joined
1724 2012-08-20 19:56:56 <gavinandresen> BlueMatt: what does block-chain-tester do?  Waits for incoming connections, or connects to random nodes ? And is it testnet?
1725 2012-08-20 19:56:57 <BlueMatt> justmoon: another thing you may wanna check out for testing ^, but it doesnt test as many interesting corner-cases, its more of a sanity-check
1726 2012-08-20 19:57:41 <BlueMatt> gavinandresen: connects to 127.0.0.1 (and its mainnet, but requires a patch to use a lower pow min, diff genesis, etc)
1727 2012-08-20 19:58:41 att has quit (Ping timeout: 255 seconds)
1728 2012-08-20 19:59:22 <gavinandresen> BlueMatt: block-chain-tester is a sanity testing tool? I'm still not clear what it is meant to test
1729 2012-08-20 19:59:52 <BlueMatt> it connects to a local node and feeds it a chain (incl reorgs, invalid blocks, etc) and test that the node it connected to is accepting/rejecting blocks as it should
1730 2012-08-20 20:00:27 <gavinandresen> ok, cool.  What happens if a test fails?
1731 2012-08-20 20:01:15 <justmoon> gavinandresen: the committer is mailed a dead pidgeon - there really are webservices for everything these days
1732 2012-08-20 20:01:25 <BlueMatt> gavinandresen: it says "Blocks which were not handled the same between bitcoind/bitcoinj: " ...
1733 2012-08-20 20:01:27 <gavinandresen> mmmm, pigeon....
1734 2012-08-20 20:01:37 <TD> BlueMatt: neat
1735 2012-08-20 20:01:38 <BlueMatt> gavinandresen: plan is, if it finds any, marks pulls as failing tests
1736 2012-08-20 20:01:46 <justmoon> TD: did you see my email?
1737 2012-08-20 20:01:49 <gavinandresen> BlueMatt: spiffy-rific
1738 2012-08-20 20:01:54 <justmoon> TD: sorry about late response
1739 2012-08-20 20:02:15 * justmoon just tried to autocomplete the word sorry by pressing TAB
1740 2012-08-20 20:02:43 <gavinandresen> BlueMatt: so to answer your original question: no, go nuts running stuff on jenkins.  CPU usage is free.
1741 2012-08-20 20:02:53 <BlueMatt> alrighty
1742 2012-08-20 20:02:59 <TD> justmoon: sorry, must have been a bad merge on my part somewhere. i'll check that fix in ASAP
1743 2012-08-20 20:03:13 <justmoon> TD: it might not be the only problem - but we'll see
1744 2012-08-20 20:07:31 <jgarzik> heh, height in coinbase
1745 2012-08-20 20:07:35 iocor has joined
1746 2012-08-20 20:07:36 <jgarzik> er
1747 2012-08-20 20:07:40 <jgarzik> yay, height in coinbase
1748 2012-08-20 20:07:42 JStoker has joined
1749 2012-08-20 20:07:47 <jgarzik> finally
1750 2012-08-20 20:07:59 <jgarzik> Luke-Jr: branch away
1751 2012-08-20 20:08:12 <Luke-Jr> ?
1752 2012-08-20 20:09:27 <jgarzik> Luke-Jr: the height-in-coinbase change itself wants backporting
1753 2012-08-20 20:09:32 <jgarzik> IMO it is a bugfix
1754 2012-08-20 20:10:06 <Luke-Jr> it doesn't fix any bugs?
1755 2012-08-20 20:10:36 <jgarzik> Luke-Jr: it avoids duplicate coinbase possibility
1756 2012-08-20 20:10:49 <Luke-Jr> jgarzik: that was already impossible, thanks to BIP 30
1757 2012-08-20 20:10:55 <jgarzik> not quite
1758 2012-08-20 20:10:56 graingert has quit (Remote host closed the connection)
1759 2012-08-20 20:10:58 <Luke-Jr> ?
1760 2012-08-20 20:11:03 <jgarzik> this was already discussed
1761 2012-08-20 20:12:20 <Luke-Jr> in any case, porting to poolservers is probably of higher importance IMO
1762 2012-08-20 20:14:05 rdponticelli has joined
1763 2012-08-20 20:15:48 <Luke-Jr> why does BIP34 say Gavin wrote it? I thought jgarzik did
1764 2012-08-20 20:16:34 <gavinandresen> because I'm an attention-grabbing whore.
1765 2012-08-20 20:16:50 <wizkid057> +1 ?
1766 2012-08-20 20:16:52 <Luke-Jr> more importantly, if BIP 30 didn't fix the problem, I'd have expected to see at least a brief explanation where it failed in 34 :p
1767 2012-08-20 20:19:05 <phantomcircuit_> gavinandresen, lawl
1768 2012-08-20 20:19:10 danbri has joined
1769 2012-08-20 20:19:24 <Luke-Jr> anyone have a link that explains that?
1770 2012-08-20 20:19:28 <Luke-Jr> or discussion of it?
1771 2012-08-20 20:19:53 <BlueMatt> link: data://"bip30 still allows duplicates after they are spent"
1772 2012-08-20 20:19:55 <wizkid057> seems like BIP34 would be a perfect time to expand the possible nonce incrementing bits...
1773 2012-08-20 20:19:55 <Luke-Jr> (fwiw, I'm not questioning it, just feel it's something I should understand to properly update Eloipool)
1774 2012-08-20 20:21:10 <Luke-Jr> BlueMatt: hmm, that's it?
1775 2012-08-20 20:22:03 <BlueMatt> thats not the only reason to put coinbases in blocks, but afaik, thats it on actual can-duplicate-coinbase scenarios (aside from if its before the switch timestamp)
1776 2012-08-20 20:22:20 <BlueMatt> s/coinbases in blocks/heights in coinbases/
1777 2012-08-20 20:22:41 <gmaxwell> wizkid057: There is no reason to expand the nonce incrementing bits.
1778 2012-08-20 20:23:04 <gmaxwell> (Or at least I've not seen one established)
1779 2012-08-20 20:23:11 <wizkid057> gmaxwell: well, there's certainly a reason. It may not be a very good reason, but, theres reason :)
1780 2012-08-20 20:24:17 <gmaxwell> wizkid057: "I want to change the blockchain format, probably with a hardforking change, in order to avoid making a change to my remote mining protocol to support unicorn asics where one device darn near outpaces the whole current network" is hardly a reasonable reason.
1781 2012-08-20 20:24:44 <wizkid057> well, at least we're on the same page with the ASICs
1782 2012-08-20 20:24:45 <wizkid057> lol
1783 2012-08-20 20:25:34 <Luke-Jr> gmaxwell: huh? what hardforking change?
1784 2012-08-20 20:25:39 Internet13 has quit (Ping timeout: 246 seconds)
1785 2012-08-20 20:25:40 <gmaxwell> wizkid057: Seriously, the existing nonce gives you a factor of four billion reduction in work generation. Just do local work generation... then each miner needs, I dunno, about $10 in general purpose cpu to support ever $30,000 in unicorn asics.
1786 2012-08-20 20:25:59 <gmaxwell> All your pretty pools can stay perfectly centeralized just let the client update extranonce.
1787 2012-08-20 20:26:22 <Luke-Jr> gmaxwell: actually, in real world testing, a single $30k SC MiniRig requires a dedicated i7 CPU right now
1788 2012-08-20 20:26:43 <Luke-Jr> and presumably that's with less-than-full blocks
1789 2012-08-20 20:26:54 <wizkid057> gmaxwell: i'm fully in favor of a reenvisioned, binary mining protocol
1790 2012-08-20 20:27:16 <wizkid057> using HTTP and HTTP "longpolls" is silly
1791 2012-08-20 20:27:20 <wizkid057> imo
1792 2012-08-20 20:29:11 <Luke-Jr> (note: the 1 TH/s isn't from an actual SC MiniRig in this case)
1793 2012-08-20 20:29:19 lunchtime has joined
1794 2012-08-20 20:29:29 <gmaxwell> Luke-Jr: stop using python miner code, fool.
1795 2012-08-20 20:30:09 <wizkid057> gmaxwell: hmm... we're on two pages... haha
1796 2012-08-20 20:30:11 <Luke-Jr> gmaxwell: faster than bitcoind's C++ at least </troll>
1797 2012-08-20 20:30:26 minimoose has quit (Quit: minimoose)
1798 2012-08-20 20:30:32 lunchtime is now known as luncht1me
1799 2012-08-20 20:30:40 justmoon has quit (Quit: Leaving)
1800 2012-08-20 20:31:39 <Luke-Jr> gmaxwell: on that note, the main thing holding me back from porting Eloipool to C++ is that C++ requires stopping the program to debug; do you know any way to integrate GDB or similar so they can debug without stopping the program?
1801 2012-08-20 20:31:44 <gmaxwell> Luke-Jr: well not if need an i7 cpu to generate work for a 1TH rig! .. as that only requires something like 256 works per second or so.
1802 2012-08-20 20:32:03 <gmaxwell> Luke-Jr: you fork and write a core file from the fork.
1803 2012-08-20 20:32:04 <TD> Luke-Jr: there's a google library that allows a running program to core dump itself without stopping
1804 2012-08-20 20:32:25 <gmaxwell> Luke-Jr: it's like ... 6 lines of code to implement that.
1805 2012-08-20 20:32:28 <Luke-Jr> core dumps are infinitely less useful :p
1806 2012-08-20 20:32:33 <TD> the lib supports multithreaded core dumps, which can be tricky if you just fork
1807 2012-08-20 20:32:47 <TD> well if you want real-time interactive debugging without stopping, i guess the answer is no and you already know it ;)
1808 2012-08-20 20:32:52 <gmaxwell> TD: okay, point.
1809 2012-08-20 20:32:57 <Luke-Jr> I like to modify running code.
1810 2012-08-20 20:33:07 <gmaxwell> Luke-Jr: you could write a GDB remote debugger client into it.
1811 2012-08-20 20:33:15 <gmaxwell> Luke-Jr: but I don't know much about actually _creating_ one.
1812 2012-08-20 20:33:19 <Luke-Jr> hmm
1813 2012-08-20 20:33:25 <Luke-Jr> that might be interesting to look into
1814 2012-08-20 20:33:58 <gmaxwell> but really, if dumping is ~free... snapshot and go isn't bad.. and if you want to poke you script it so the interuption is minimal.
1815 2012-08-20 20:34:32 <gmaxwell> or make a super light loadbalancing shim that feeds N backends, and then when you break a backend the traffic just goes to the other one.
1816 2012-08-20 20:35:22 <Luke-Jr> right now, I can replace functions on the fly to debug, and existing/new connections use them. it's quite convenient.
1817 2012-08-20 20:36:05 <wizkid057> well, sacrificing a little coding convenience is a small price to pay for an exponential speedup
1818 2012-08-20 20:36:35 <Luke-Jr> maybe.
1819 2012-08-20 20:36:48 <Luke-Jr> the remote target thing might work good enough
1820 2012-08-20 20:37:51 <wizkid057> shouldn't be running anything unstable enough to require on the fly debugging on a production node anyway :D
1821 2012-08-20 20:38:13 <gmaxwell> Luke-Jr: seriously, 1TH/s should require just a few hundred getworks/s. The getwork should require three sha256 operations.  I wouldn't recommend powering hundreds of thouands of dollars of mining hardware with a <$100 atom board, but with efficient code it should be perfectly possible.
1822 2012-08-20 20:38:32 <gmaxwell> Luke-Jr: I think the gdb remote target will still break the thing when broken though, so perhaps not.
1823 2012-08-20 20:39:06 <Luke-Jr> gmaxwell: why would getwork get by with 3 SHA256 ops?
1824 2012-08-20 20:39:14 <Luke-Jr> it has to rebuild the merkle tree…
1825 2012-08-20 20:39:31 eian has joined
1826 2012-08-20 20:40:08 <TD> Luke-Jr: what is it written in currently?
1827 2012-08-20 20:40:09 <gmaxwell> Luke-Jr: it has to update the coinbase. Which should require hashing the coinbase txn, then hashing the result with the neighbor. Then building the midstate (I assume).
1828 2012-08-20 20:40:13 <Luke-Jr> TD: Python3
1829 2012-08-20 20:40:16 <TD> ok
1830 2012-08-20 20:40:22 <gmaxwell> Luke-Jr: why do you think you have to rebuild the whole tree?
1831 2012-08-20 20:40:26 <TD> you can debug java interactively to some extent (hot swapping methods, etc)
1832 2012-08-20 20:40:31 <TD> of course if you want the ultimate in that then you need a lisp
1833 2012-08-20 20:40:37 <Luke-Jr> gmaxwell: to change the coinbase, you need to hash it with the neighbor, all the way up the tree
1834 2012-08-20 20:40:45 <wizkid057> because i think thats what eloipool does now, rebuilds the whole tree
1835 2012-08-20 20:41:30 <Luke-Jr> 2 + sqrt(txncount) times I think
1836 2012-08-20 20:41:50 <gmaxwell> log2()
1837 2012-08-20 20:41:53 <Luke-Jr> right
1838 2012-08-20 20:41:53 <wizkid057> wouldnt it be log2(txncount)
1839 2012-08-20 20:41:54 <eian> log2
1840 2012-08-20 20:41:55 <wizkid057> yeah
1841 2012-08-20 20:41:56 <wizkid057> lol
1842 2012-08-20 20:41:58 <Luke-Jr> >_<
1843 2012-08-20 20:42:27 <wizkid057> well
1844 2012-08-20 20:42:39 <wizkid057> you could solve all of these issues by just not mining any transactions :P
1845 2012-08-20 20:42:40 <gmaxwell> Luke-Jr: ah, duh, right you are. _Fine_, 14 hashes. so under 4000 hashes per second.
1846 2012-08-20 20:42:46 nsh has joined
1847 2012-08-20 20:42:56 <amiller> there's no such thing as a block without a coinbase tranasction is there?
1848 2012-08-20 20:43:05 <TD> no
1849 2012-08-20 20:43:07 <amiller> the coinbase transaction is always the txout with index 0, and the txout with index 0 is always coinbase
1850 2012-08-20 20:43:11 <TD> the coinbase is, by definition, the first tx
1851 2012-08-20 20:43:13 <amiller> kk
1852 2012-08-20 20:43:31 <wizkid057> i meant other transactions
1853 2012-08-20 20:43:39 <Luke-Jr> gmaxwell: probably that statistic was skewed by the 1 TH/s  not being a real ASIC rig then :/
1854 2012-08-20 20:43:51 <gmaxwell> Luke-Jr: some slow cpu should be able to do a good million per second with a core.
1855 2012-08-20 20:44:14 <wizkid057> gmaxwell: you're assuming compiled code, also
1856 2012-08-20 20:44:19 rdponticelli has quit (Ping timeout: 260 seconds)
1857 2012-08-20 20:44:20 <gmaxwell> Yes, I am.
1858 2012-08-20 20:44:57 <gmaxwell> Again, we don't change the protcol because someone with _tens of thousands of dollars in hardware_ is too greedy to kick a grand to a developer to write a reasonably efficient tool.
1859 2012-08-20 20:45:36 <Luke-Jr> lol
1860 2012-08-20 20:46:42 Internet13 has joined
1861 2012-08-20 20:46:52 <wizkid057> i wonder what the least amount of data the miner would need to rehash the coinbase would be
1862 2012-08-20 20:47:04 <Luke-Jr> technically speaking, we're about to change the protocol to make it harder ;)
1863 2012-08-20 20:47:15 <Luke-Jr> since before, the block version could be set to anything
1864 2012-08-20 20:47:42 <wizkid057> but it seems that was frowned upon
1865 2012-08-20 20:48:15 <Luke-Jr> I don't know that anyone had tried it
1866 2012-08-20 20:48:21 <wizkid057> well, do it
1867 2012-08-20 20:48:24 <wizkid057> lol
1868 2012-08-20 20:48:44 <Luke-Jr> at this point, I think the other devs would lynch me for that :P
1869 2012-08-20 20:48:47 JStoker has quit (Excess Flood)
1870 2012-08-20 20:48:58 <gmaxwell> wizkid057: the log2(txn) tree fragments, the coinbase txn, the header template, and the extranonce range.
1871 2012-08-20 20:49:23 <gmaxwell> they for each share they'd return the header and the extranonce value.
1872 2012-08-20 20:49:42 <gmaxwell> (and the initial work ID, e.g. with extranonce 0 or whatever)
1873 2012-08-20 20:49:42 <wizkid057> set the block version to 57495a4b :P
1874 2012-08-20 20:49:58 * wizkid057 wonders what would happen if he did this for his solo efforts...
1875 2012-08-20 20:52:29 danbri has quit (Remote host closed the connection)
1876 2012-08-20 20:52:30 jurov is now known as away!xzbnxup@84.245.71.31|jurov
1877 2012-08-20 20:52:34 <TD> BlueMatt: sorry, expect me to go back and delete some review comments as i realize they are irrelevant
1878 2012-08-20 20:52:41 <TD> i think github publishes them immediately doesn't it
1879 2012-08-20 20:53:26 <BlueMatt> TD: it does, but no worry, Im working on packaging the comparison tool for jenkins right now, Ill read all the comments sometime later (probably after dinner)
1880 2012-08-20 20:53:41 <TD> ok
1881 2012-08-20 20:53:53 <TD> i'm used to mondrian/critique where it saves up comments and publishes them in a batch at the end
1882 2012-08-20 20:54:58 <BlueMatt> TD: does eclipse have an easy 1-button feature to package up a runnable-jar from a given class/run configuration?
1883 2012-08-20 20:55:26 <TD> not sure, i don't use eclipse. i'd hope so.
1884 2012-08-20 20:55:41 <BlueMatt> heh, nevermind, found it
1885 2012-08-20 20:56:18 phantomcircuit_ is now known as phantomcircuit
1886 2012-08-20 20:57:15 cande has quit (Remote host closed the connection)
1887 2012-08-20 20:57:40 mrdavis has joined
1888 2012-08-20 20:58:09 mrdavis has left ()
1889 2012-08-20 20:58:56 <Ferroh> abbreviate the word "round"
1890 2012-08-20 20:59:04 <Ferroh> I guess you cant :(
1891 2012-08-20 21:01:56 <jurov> hi amiller, did you find out?
1892 2012-08-20 21:02:09 <amiller> find out?
1893 2012-08-20 21:02:28 <jurov> <amiller> [21:26:49] jurov|away, why is "isCoinbase" needed to validate an input?
1894 2012-08-20 21:04:57 <amiller> yeah apparently there is a 'maturity' requirement that i wasn't previously aware of
1895 2012-08-20 21:05:29 <gmaxwell> 0_o
1896 2012-08-20 21:06:16 <Luke-Jr> lol
1897 2012-08-20 21:13:42 JStoker has joined
1898 2012-08-20 21:14:09 RainbowDashh is now known as in
1899 2012-08-20 21:14:51 darksk1ez has joined
1900 2012-08-20 21:19:37 <genjix> TD: so what's your ideal time?
1901 2012-08-20 21:19:47 <TD> probably more like 30 mins
1902 2012-08-20 21:20:09 <TD> but i don't want to be significantly longer than the other talks. so i can work with whatever fits
1903 2012-08-20 21:20:30 danbri has joined
1904 2012-08-20 21:21:27 <phantomcircuit> genjix, yubikeys on the way
1905 2012-08-20 21:21:48 * Luke-Jr intercepts genjix's yubikeys
1906 2012-08-20 21:21:48 <phantomcircuit> yubico only has DHL express shipping in the uk so you'll probably get them tomorrow or the next day
1907 2012-08-20 21:21:57 <phantomcircuit> Luke-Jr, shrug
1908 2012-08-20 21:22:10 <phantomcircuit> mail theft over $200 in yubikeys isn't a great plan
1909 2012-08-20 21:23:27 danbri has quit (Remote host closed the connection)
1910 2012-08-20 21:24:05 <midnightmagic> phantomcircuit: how many yubikeys did you manage to get for $200?
1911 2012-08-20 21:25:00 <phantomcircuit> 10
1912 2012-08-20 21:25:31 <midnightmagic> if you have any troubles getting the yubikey-awake pam modules going on BSD, let me know :)
1913 2012-08-20 21:25:40 <midnightmagic> *aware
1914 2012-08-20 21:25:41 <phantomcircuit> it was actually like 270 with shipping and taxes
1915 2012-08-20 21:26:03 <midnightmagic> phantomcircuit: where did you have them shipped to? i thought they have a facility in.. california or something
1916 2012-08-20 21:26:13 <phantomcircuit> amir in the uk
1917 2012-08-20 21:26:24 <phantomcircuit> they have a facility in the uk too but apparently only offer dhl express
1918 2012-08-20 21:26:29 <midnightmagic> doh
1919 2012-08-20 21:26:30 <phantomcircuit> which i suspect is bullshit but oh well
1920 2012-08-20 21:27:28 rdponticelli has joined
1921 2012-08-20 21:28:06 <midnightmagic> ah cool, they have a yubikey nano now. slick
1922 2012-08-20 21:29:57 <phantomcircuit> lol
1923 2012-08-20 21:30:07 <phantomcircuit> i have a microSD reader about that size
1924 2012-08-20 21:30:12 <phantomcircuit> you *will* get it stuck
1925 2012-08-20 21:32:42 Zarutian has quit (Quit: Zarutian)
1926 2012-08-20 21:33:40 <TD> BlueMatt: ok, i finished my review
1927 2012-08-20 21:33:44 <TD> BlueMatt: looks really good
1928 2012-08-20 21:36:57 yellowhat has quit (Changing host)
1929 2012-08-20 21:36:57 yellowhat has joined
1930 2012-08-20 21:38:37 <Raccoon> Who primarily works on bitcoin-qt's UI?
1931 2012-08-20 21:39:22 <phantomcircuit> Raccoon, open up git and
1932 2012-08-20 21:39:25 <phantomcircuit> git blame
1933 2012-08-20 21:39:31 <phantomcircuit> see who last edited
1934 2012-08-20 21:39:46 RazielZ has quit (Ping timeout: 245 seconds)
1935 2012-08-20 21:39:59 <Raccoon> that assumes I know how to use git
1936 2012-08-20 21:41:33 <phantomcircuit> https://github.com/bitcoin/bitcoin/blame/master/src/qt/aboutdialog.cpp
1937 2012-08-20 21:46:33 <gmaxwell> hm. does decoderawtransaction show the sighash type in a way I'm missing?
1938 2012-08-20 21:48:20 spitteler has quit (Ping timeout: 276 seconds)
1939 2012-08-20 21:50:21 in has quit (Read error: Connection reset by peer)
1940 2012-08-20 21:50:58 slush has joined
1941 2012-08-20 21:51:17 <gavinandresen> gmaxwell: last byte in the scriptsig...
1942 2012-08-20 21:52:19 in has joined
1943 2012-08-20 21:52:41 <genjix> phantomcircuit: yay... i guess.
1944 2012-08-20 21:54:17 * genjix will look frantically for any special hidden packages inside the seemingly dull one
1945 2012-08-20 21:55:17 <genjix> awaiting a happy weekend.
1946 2012-08-20 21:55:24 <gmaxwell> Speaking of the GUI— what happened to all that neat GUI work that was going on a few months ago with the sidebar refactoring and stuff?
1947 2012-08-20 21:55:29 rdponticelli has quit (Ping timeout: 260 seconds)
1948 2012-08-20 21:58:48 <BlueMatt> Raccoon: laanjw aka wumpus
1949 2012-08-20 21:58:57 <BlueMatt> and Diapolo
1950 2012-08-20 21:59:17 <BlueMatt> TD: thanks, Ill respond soon
1951 2012-08-20 21:59:29 <Raccoon> thanks BlueMatt
1952 2012-08-20 22:02:17 jurov is now known as jurov|away
1953 2012-08-20 22:05:41 copumpkin has quit (Quit: Computer has gone to sleep.)
1954 2012-08-20 22:07:09 Marf has quit (Ping timeout: 260 seconds)
1955 2012-08-20 22:09:38 tower has quit (Ping timeout: 252 seconds)
1956 2012-08-20 22:11:59 LuaKT has quit ()
1957 2012-08-20 22:13:33 denisx has quit (Quit: denisx)
1958 2012-08-20 22:15:06 tower has joined
1959 2012-08-20 22:15:37 sirk390 has quit (Quit: Leaving.)
1960 2012-08-20 22:16:47 da2ce7_d has quit (Remote host closed the connection)
1961 2012-08-20 22:18:26 da2ce7_d has joined
1962 2012-08-20 22:19:23 denisx has joined
1963 2012-08-20 22:21:09 luncht1me has quit (Quit: —I-n-v-i-s-i-o-n— 3.3 (November '11) , You know what time it is)
1964 2012-08-20 22:21:40 TD has quit (Quit: TD)
1965 2012-08-20 22:22:02 <genjix> https://bitcointalk.org/index.php?topic=101734.0
1966 2012-08-20 22:22:07 <genjix> isnt this like amillers project?
1967 2012-08-20 22:22:23 <genjix> oh lol it is amiller
1968 2012-08-20 22:24:44 gfinn has quit (Ping timeout: 276 seconds)
1969 2012-08-20 22:25:19 wereHamster has quit (Ping timeout: 245 seconds)
1970 2012-08-20 22:26:03 wereHamster has joined
1971 2012-08-20 22:26:15 toffoo has joined
1972 2012-08-20 22:27:00 cjd has joined
1973 2012-08-20 22:27:54 copumpkin has joined
1974 2012-08-20 22:27:55 copumpkin has quit (Changing host)
1975 2012-08-20 22:27:55 copumpkin has joined
1976 2012-08-20 22:28:13 theymos has joined
1977 2012-08-20 22:29:25 <cjd> Anyone here know what became of cia.vc? looks like it's been down for a few days now.. I figured I'd ask here since word gets around pretty quick in these parts.
1978 2012-08-20 22:30:27 <genjix> cjd: hey!
1979 2012-08-20 22:30:43 * cjd waves
1980 2012-08-20 22:31:59 CodesInChaos has quit (Ping timeout: 240 seconds)
1981 2012-08-20 22:34:59 vampireb has quit (Quit: Lost terminal)
1982 2012-08-20 22:37:43 gfinn has joined
1983 2012-08-20 22:42:06 rdponticelli has joined
1984 2012-08-20 22:44:04 <midnightmagic> cjd..? the netbsd guy?
1985 2012-08-20 22:44:21 <midnightmagic> woops my mistake, sorry.
1986 2012-08-20 22:45:33 tsche has joined
1987 2012-08-20 22:47:29 rdponticelli has quit (Ping timeout: 276 seconds)
1988 2012-08-20 22:47:41 Turingi has quit (Read error: Connection reset by peer)
1989 2012-08-20 22:49:22 <genjix> midnightmagic: the cjdns guy
1990 2012-08-20 22:49:27 <genjix> cool project, check it out.
1991 2012-08-20 22:49:48 theymos has quit (Remote host closed the connection)
1992 2012-08-20 22:54:38 ovidiusoft has quit (Ping timeout: 276 seconds)
1993 2012-08-20 22:56:30 <BlueMatt> cjd: ask Diablo-D3, maybe?
1994 2012-08-20 22:56:50 <cjd> thanks
1995 2012-08-20 22:56:58 rickbauss has quit (Ping timeout: 244 seconds)
1996 2012-08-20 22:58:22 <sipa> amiller: yes, i decode the entire utxo data for a given tx, when pulling the coindata from the database to the cache
1997 2012-08-20 22:58:40 <sipa> amiller: after that, all operations directly operate on the exact utxo
1998 2012-08-20 22:59:59 <amiller> that means you have an extra quantity in there right, O(T + log M), where T is the transaction size, roughly proportional to the number of inputs+outputs?
1999 2012-08-20 23:00:26 <sipa> amiller: sure indexing in txid:outindex would be more efficient, but this allows a much smaller database (as the txids aren't duplicated), which results in a smaller working set, which may improve performance as well
2000 2012-08-20 23:00:45 <amiller> it's more important post-merke-commitment
2001 2012-08-20 23:00:46 <sipa> amiller: and indeed, it's stored in coins.dat, which contains serialized utxo per txid data, and the best chain pointer
2002 2012-08-20 23:01:33 <sipa> amiller: you'd use two indexes, one txid:outindex -> hash(pubkeyscript), and then a second index hash(pubkeyscript)->pubkeyscript? i doubt that's worth it
2003 2012-08-20 23:02:25 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
2004 2012-08-20 23:03:09 <amiller> it requires a larger database because you need to more of your transactions
2005 2012-08-20 23:03:22 <amiller> and you have to keep the entirety of the transactions you keep[
2006 2012-08-20 23:03:43 <amiller> you can discard the hash(pubkeyscript)->pubkeyscript of a txoutput once you're done with it
2007 2012-08-20 23:04:15 bakh_ has quit (Quit: Ex-Chat)
2008 2012-08-20 23:04:54 ByronJohnson has quit (Ping timeout: 246 seconds)
2009 2012-08-20 23:05:04 <sipa> amiller: sure, but there are on average only 2 utxo's with the same script
2010 2012-08-20 23:05:17 <sipa> a scripthash is 32 bytes? 20 bytes maybe?
2011 2012-08-20 23:05:25 <sipa> i use 21.2 byte on average per script
2012 2012-08-20 23:05:47 <amiller> but you have to store all the inputs as well
2013 2012-08-20 23:05:58 <amiller> or at least you do if you validate the transaction against a hash when you load it
2014 2012-08-20 23:06:06 <sipa> inputs?
2015 2012-08-20 23:06:07 <sipa> ?
2016 2012-08-20 23:06:18 <amiller> the transaction data contains a list of txinputs and txoutputs
2017 2012-08-20 23:06:38 <amiller> you need to recompute a hash over all of them to verify that the transaction data matches the txid
2018 2012-08-20 23:06:40 <sipa> yes, the part of the db brought into the cache is that of all txids from which coins are consumed
2019 2012-08-20 23:07:53 <sipa> amiller: and the serialized coin also contains some bit vector + its size, to know which txouts are still unspent
2020 2012-08-20 23:09:02 <sipa> not all choices i made result in the best asymptotical or worst-case behaviour, but in terms of practical average-case performance it's quite good :)
2021 2012-08-20 23:09:56 <amiller> fair enough, but i'm trying to use ultraprune to understand the trie proposals
2022 2012-08-20 23:11:58 ByronJohnson has joined
2023 2012-08-20 23:14:35 <amiller> the worst-case validation cost right now is quadratic in the size of a transaction
2024 2012-08-20 23:16:59 tower has quit (Ping timeout: 240 seconds)
2025 2012-08-20 23:17:27 <amiller> O(T^2 + T log M)  if T is the maximum number of txinputs
2026 2012-08-20 23:18:05 <BlueMatt> ;;later tell TD oops, one more that I somehow rebased out of the tree...(now pushed to fullverif)
2027 2012-08-20 23:18:05 <gribble> The operation succeeded.
2028 2012-08-20 23:18:13 <amiller> that is relevant to the discussion about sweeping up inputs
2029 2012-08-20 23:24:02 tower has joined
2030 2012-08-20 23:27:47 agricocb has quit (Ping timeout: 276 seconds)
2031 2012-08-20 23:31:05 Anduck has quit (Ping timeout: 256 seconds)
2032 2012-08-20 23:38:16 <genjix> sipa: do you still need a place to stay in london?
2033 2012-08-20 23:38:34 <genjix> i need to ask my friend if it's ok.
2034 2012-08-20 23:40:40 <sipa> amiller: why quadratic?
2035 2012-08-20 23:40:43 Z0rZ0rZ0r has joined
2036 2012-08-20 23:40:51 <sipa> genjix: oh, i'll just book a hotel, no worries
2037 2012-08-20 23:41:23 <genjix> ok
2038 2012-08-20 23:41:47 <sipa> amiller: you mean (the number of inputs) times (the average number of outputs of the prevouts)
2039 2012-08-20 23:42:14 <amiller> there's eventually an input for every output, so those are basically the same quantity
2040 2012-08-20 23:43:36 <sipa> amiller: if that was true, the UTXO set would be of on average constant size
2041 2012-08-20 23:43:45 <sipa> but yes, they are comparable, agree
2042 2012-08-20 23:43:54 <amiller> i want to assume that eventually that must be th case
2043 2012-08-20 23:43:58 <amiller> or that the UTXO set has a bounded size
2044 2012-08-20 23:44:10 <amiller> "stabilizing input" would be the name of this assumption
2045 2012-08-20 23:44:53 <amiller> it's okay if the blockchain grows forever, but it's probably not okay if the UTXO set grows forever
2046 2012-08-20 23:45:05 <sipa> i think that's inevitable that it will grow
2047 2012-08-20 23:45:13 <sipa> but maybe slower than moore's law :)
2048 2012-08-20 23:46:38 <amiller> anyway if they're not the same
2049 2012-08-20 23:46:45 <amiller> then it means the average number of outputs is larger than the number of inputs
2050 2012-08-20 23:46:53 <amiller> (clearly it doesn't go the other way forever)
2051 2012-08-20 23:48:19 <amiller> so it's at least quadratic in the average number of inputs
2052 2012-08-20 23:48:30 <sipa> indeed
2053 2012-08-20 23:52:18 <sipa> amiller: btw, i imported a full chain and afterwards kept running as a normal node for a few hours, 118 MiB RES now according to top
2054 2012-08-20 23:52:34 D34TH_ has joined
2055 2012-08-20 23:53:29 Maged has joined
2056 2012-08-20 23:55:05 D34TH has quit (Ping timeout: 276 seconds)