1 2012-11-06 00:43:14 <etotheipi_> sipa, I don't know what you mean about "unbalanced tries"... a 256-fanout trie will require 32 hops to get to a leaf, no matter how the data is distributed... a PATRICIA or DlB or Hybrid tree will be considerably less (probably only a few hops), and the worst a mischievous person can do is require you do to more hops on some sub-branches ...
  2 2012-11-06 00:44:01 <etotheipi_> sipa: but it would be a lot of work for them to take your runtimes on that branch into territory that you were already comfortable with... 32
  3 2012-11-06 00:44:55 <etotheipi_> In reality, with a PATRICIA tree, you're probably doing 5-6 hops, maybe 7 or 8 if the UTXO space jumps up a copule orders of magnitude
  4 2012-11-06 00:45:28 <etotheipi_> and those top 3 or 4 levels can be cached
  5 2012-11-06 00:45:45 <etotheipi_> they won't change like a binary tree would (which can rebalance and shift your nodes around in and out of the cache)
  6 2012-11-06 00:46:11 <amiller> you're thinking of this as a data structure in ram, and that's probably not going to be the case
  7 2012-11-06 00:46:22 <etotheipi_> uh oh
  8 2012-11-06 00:46:36 <etotheipi_> eto and amiller on the same IRC channel talking about data structures
  9 2012-11-06 00:46:37 <etotheipi_> run!
 10 2012-11-06 00:46:47 <amiller> it's a logical data structure, because we're just talking about what you have to do to compute and _validate_ the updated root hashes
 11 2012-11-06 00:47:05 <etotheipi_> why can't patricia trees be disk-based?
 12 2012-11-06 00:47:37 <amiller> well the thing is neither patricia tries nor binary trees are efficient on disk
 13 2012-11-06 00:47:52 <etotheipi_> probably true, but probably unavoidable
 14 2012-11-06 00:48:07 <amiller> if you want random access disk efficiency you'd want a b-tree, which is problematic because we'd have to pick one cache size for everyone
 15 2012-11-06 00:48:26 <amiller> if you are a full validating light-client
 16 2012-11-06 00:48:37 <amiller> you do not need to perform random accesses
 17 2012-11-06 00:48:46 <etotheipi_> but at the very least, the top few levels of the Patricia tree can be cached into RAM
 18 2012-11-06 00:48:50 <amiller> you can let the network feed you the right answers
 19 2012-11-06 00:48:53 <etotheipi_> which would dramatically reduce random accesses
 20 2012-11-06 00:49:11 <etotheipi_> if you're usually only making 5-6 hops but 3-4 are cached...
 21 2012-11-06 00:49:37 <etotheipi_> (er... 4 is a bit much)
 22 2012-11-06 00:50:42 <amiller> do you agree that a) after-the-fact validation and b) random access queries are two different algorithms / use cases and the ideal data structure for one may be worse for the other?
 23 2012-11-06 00:50:48 <etotheipi_> but I'm sure the same cache optimization is still avialable for the binary trees
 24 2012-11-06 00:51:31 <etotheipi_> no, I haven't seen that distinction... unless I misunderstood you
 25 2012-11-06 00:52:02 <amiller> it's crucial, so let me try rephrasing it so that distinction comes across
 26 2012-11-06 00:56:36 <amiller> uh, well lets just say that there are a variety of different size clients on the network
 27 2012-11-06 00:56:45 <amiller> some of them may have enough memory to hold the UTXO set
 28 2012-11-06 00:56:58 <amiller> but many of them may have a smaller size amount of memory
 29 2012-11-06 00:57:23 <amiller> and in addition to having a finite amount of memory they may have various caches
 30 2012-11-06 00:57:44 <wizkid057> how about a distributed hash table? :D
 31 2012-11-06 00:58:02 <amiller> the whole point of doing this merkle tree commitment thing is that it becomes possible for a node with memory limit m < M (utxo set size) to perfectly validate each transaction
 32 2012-11-06 00:58:32 <amiller> if you have less memory than the UTXO set, then you are going to rely on an untrusted service (like the distributed p2p network itself) to provide you with answers, but you're going to check them yourself
 33 2012-11-06 00:58:32 <etotheipi_> amiller, correct (following you so far)
 34 2012-11-06 00:59:19 <amiller> so if you only have memory m, and the utxo is size M, then you are definitely not going to store a binary tree with pointers
 35 2012-11-06 00:59:44 <amiller> but what then is the optimal strategy to validate transactions?
 36 2012-11-06 01:00:21 <etotheipi_> amiller, one of my points about PATRICIA trees was that those light nodes can easily store the small subtrees
 37 2012-11-06 01:00:34 <etotheipi_> and only need to retrieve the hash information for each node that leads up to that subtree
 38 2012-11-06 01:00:40 <etotheipi_> to do that validation
 39 2012-11-06 01:01:14 <etotheipi_> in fact, one of my concerns with the binary tree, is that all subnodes of a given address may be distributed across multiple sub-branches
 40 2012-11-06 01:01:15 <amiller> that validation involves computing a lot of hashes
 41 2012-11-06 01:01:37 <etotheipi_> I don't know how you would even specify that, or communicate it... without specifying a lot of other information the node doesn't need
 42 2012-11-06 01:02:25 <amiller> what i want to optimize is, for validation, and with memory size m, what's 1) the minimum number of hashes you have to recompute, 2) what's the least amount of network access you need to have, and 3) what's the fewest number of i/os you need
 43 2012-11-06 01:02:39 <etotheipi_> well, let me state that a little better:  it's going to be complicated for one network node to communicate to another, that its address owns N UTXOs, and here's where they are on the tree
 44 2012-11-06 01:04:32 <etotheipi_> amiller, by those metrics, I agree that trie-based structures are weaker (unless there was a good associative hashing algorithm available)
 45 2012-11-06 01:04:34 <amiller> every chunk of blockchain is a linear sequence of insertions or deletions to the utxo, and validation means checking that each one is valid and that the root hash after every sequence is correct
 46 2012-11-06 01:05:49 <etotheipi_> amiller, quick verification:  is this tree keyed only by address?  address||outpoint?
 47 2012-11-06 01:06:12 <etotheipi_> I originally proposed keyed by address, and then that leaf would hold the hash value of a subtree
 48 2012-11-06 01:06:41 <etotheipi_> if it's keyed by address||outpoint , then the nodes are sorted by address first, but the leaves are the UTXOs
 49 2012-11-06 01:07:04 <etotheipi_> but yes, I understand your comments about validation
 50 2012-11-06 01:07:08 <amiller> hm, no i definitely haven't been thinking of it that way, but i acknowledge that that was around from the beginning
 51 2012-11-06 01:07:30 <amiller> i am tending to think of it keyed by txid|idx and that's all
 52 2012-11-06 01:07:36 <amiller> except that i'm also interested in having arbitrary keys
 53 2012-11-06 01:07:41 <amiller> in which case address could be one of them
 54 2012-11-06 01:08:01 <etotheipi_> well, I didn't mean "address" literally, it would basically be "txout script"
 55 2012-11-06 01:08:05 <amiller> so there would be two leaves for each utxo, one for txid|idx, and another for addr
 56 2012-11-06 01:09:43 <etotheipi_> I just want to make sure we're on the same page in this regard
 57 2012-11-06 01:10:06 <etotheipi_> I originally proposed a master tree that is keyed by address (script) and the leaves are addresses (scripts)
 58 2012-11-06 01:10:16 <etotheipi_> and that those leaves contain the root hash of a sub tree
 59 2012-11-06 01:10:44 <amiller> i don't think it makes any difference for my analysis so i'll try to switch to thinking about it in your terms
 60 2012-11-06 01:10:53 <etotheipi_> I realized that with a trie-based tree... you could have addr|outpoint and then all outpoints for a given address would be nicely contained in the subtree
 61 2012-11-06 01:10:54 <amiller> the most important thing is that the addresses are controlled by arbitrary users
 62 2012-11-06 01:11:12 <etotheipi_> okay
 63 2012-11-06 01:11:14 <amiller> so i am only really focusing on the master tree since i'm going to assume there's no address reuse
 64 2012-11-06 01:11:29 <etotheipi_> why can you assume that?
 65 2012-11-06 01:12:04 <amiller> well, by default because it's a worst-case and because it's under the control of users
 66 2012-11-06 01:12:24 <etotheipi_> oh, I thought you were making a simplifying assumption...
 67 2012-11-06 01:12:33 <etotheipi_> okay... well carry on
 68 2012-11-06 01:13:30 <amiller> so if you have memory m < M  (M is the number of unique address in the master tree)
 69 2012-11-06 01:13:38 <amiller> how to use that memory most efficiently?
 70 2012-11-06 01:13:47 <amiller> well first of the root node is going to change with every single update, guaranteed
 71 2012-11-06 01:13:58 <amiller> so you can avoid recomputing it twice
 72 2012-11-06 01:14:24 <amiller> some times you branch left sometimes you branch right, suppose that in the worst case the modifications alternate
 73 2012-11-06 01:15:10 <amiller> if you wanted to avoid recomputing that hash twice, you could just store it in memo table of already-computed node->hash(node) entries
 74 2012-11-06 01:15:28 <amiller> so here's what i think is the best solution
 75 2012-11-06 01:15:40 <amiller> when you ask the network for the validation data
 76 2012-11-06 01:16:24 <amiller> it gives you a node, and (here's the fun part) a look ahead number that tells you when you're going to need to look at that data again!
 77 2012-11-06 01:16:44 <amiller> you validate the data the first time by checking that it matches the hash you're expecting
 78 2012-11-06 01:16:55 <amiller> then you insert it into a priority queue
 79 2012-11-06 01:17:07 <etotheipi_> okay, now I lost you,
 80 2012-11-06 01:17:14 <etotheipi_> let me ponder what you said for a minute
 81 2012-11-06 01:18:00 <amiller> performing validation involves receiving a stream from an untrusted peer, as well as maintaining a priority queue of pre-validated nodes - and at each step you either read from the front of your priority queue, or from the next element in the stream
 82 2012-11-06 01:18:59 <etotheipi_> you're talking about:  you have a root hash that you know is correct (because it was in the longest chain coinbase), and you have the hash of a node you want to confirm is part of that tree
 83 2012-11-06 01:19:40 <amiller> uh it's slightly more than that let me rephrase the last part of what you said
 84 2012-11-06 01:19:57 <etotheipi_> okay, I didn't start at the same place as you
 85 2012-11-06 01:19:58 <etotheipi_> :)
 86 2012-11-06 01:20:34 <amiller> you have the root hash you know is correct, and you also have an element to insert, and you want to determine the correct root hash that results from inserting that element
 87 2012-11-06 01:21:41 <etotheipi_> I didn't think was a problem that needed to be solved
 88 2012-11-06 01:21:56 <amiller> lets do it the other way then and maybe it will be clearly
 89 2012-11-06 01:22:19 <amiller> you have a root hash you know is correct, and you have an element to remove, and you want to determine the correct root hash that results from removing that element (which includes checking that the element is in there)
 90 2012-11-06 01:23:27 <etotheipi_> I guess I'm confused, because I didn't envision this to be a problem that was in our problem space:  if you're not storing the UTXO whole tree, then you're a lite node, and your goal is just to verify the "state" of the tree at a given block, not modify that tree
 91 2012-11-06 01:23:45 <amiller> a block is a patch to the tree
 92 2012-11-06 01:24:01 <amiller> it has a sequence of updates and a new root hash
 93 2012-11-06 01:24:16 <amiller> and even the lite client needs to verify that the root hash matches the correct updates
 94 2012-11-06 01:24:17 <etotheipi_> understood
 95 2012-11-06 01:24:45 <etotheipi_> yes, it needs to verify correctness at a static moment in time (one particular block), but it doesn't need to predict the root hash for the next block
 96 2012-11-06 01:25:41 <amiller> so verifying correctness involves effectively simulating the update
 97 2012-11-06 01:25:42 <etotheipi_> it already has a mechanism for knowing that it has the correct subset of UTXOs (a verified root has for block N-3, and then 3 blocks of which each TX can be verified)
 98 2012-11-06 01:26:22 <amiller> i don't know what you mean by subset of utxos
 99 2012-11-06 01:26:44 <etotheipi_> the lite node cares about some subset of UTXOs (probably the ones relevant to its own wallet)
100 2012-11-06 01:27:25 <amiller> no the lite node needs to confirm that the new root hash is correct, given the previous root hash and the current sequence of updates
101 2012-11-06 01:27:41 <etotheipi_> I don't agree
102 2012-11-06 01:27:46 <amiller> even a lite node needs to be able to tell the difference between an invalid block and a valid block
103 2012-11-06 01:27:50 <amiller> otherwise it is unsafe to mine with
104 2012-11-06 01:27:56 <amiller> or to purchase mining power
105 2012-11-06 01:28:19 <etotheipi_> something is definitely awry here...
106 2012-11-06 01:28:26 <etotheipi_> perhaps a root of our disagreement
107 2012-11-06 01:28:52 <etotheipi_> a lite node does not need to compute/predict and then verify the next root hash
108 2012-11-06 01:29:35 <etotheipi_> it simply gets the verifiable, relevant branches for its wallet at block N, as a replacement for downloadimng the entire global blockchain history up until t that point
109 2012-11-06 01:29:45 <amiller> so it doesn't fully validate new blocks
110 2012-11-06 01:30:04 <etotheipi_> after that, it can carry on downloading new blocks as they come up
111 2012-11-06 01:30:12 <etotheipi_> and verify them against headers to know that they are legit
112 2012-11-06 01:31:12 <etotheipi_> it doesn't need to do the ECDSA validation, it only needs to know that the transactions in those blocks relevant to its wallet are valid
113 2012-11-06 01:31:20 <amiller> my definition for a "lite node" is a node that performs full validation but potentially has a very small amount of ram and disk
114 2012-11-06 01:31:49 <etotheipi_> that definitely was not my definition...
115 2012-11-06 01:31:55 <amiller> okay
116 2012-11-06 01:32:01 <etotheipi_> I figured if you're doing full validation, it's because you have enough disk space to hold the UTXO tree
117 2012-11-06 01:32:18 <amiller> my point is that's an unnecessary assumption
118 2012-11-06 01:32:19 <etotheipi_> well wait, what is "full validation"?
119 2012-11-06 01:32:30 <amiller> you can perform full validation even if you don't even have a disk at all
120 2012-11-06 01:32:33 <etotheipi_> validating every transaction, even ones that are not relevant to yoU?
121 2012-11-06 01:32:41 <amiller> yeah
122 2012-11-06 01:33:19 <etotheipi_> that doesn't sound very "lite"... how can you do that without having the whole the UTXO tree?
123 2012-11-06 01:33:31 <amiller> that's the whole point of a merkle tree!
124 2012-11-06 01:33:36 <amiller> let me explain this out
125 2012-11-06 01:33:48 <etotheipi_> okay, and I'll brb (like 3 min), keep talking
126 2012-11-06 01:34:28 <amiller> so lets just talk about a single insertion operation. the client knows the initial root hash, and the element to insert, and wants to compute the correct root hash
127 2012-11-06 01:34:46 <amiller> it receives a 'Validation Object', which is just a chunk of data from an untrusted peer
128 2012-11-06 01:35:24 <amiller> the validation object consists of the data you would visit if you traversed the tree in order, the root node first, followed by the either the left or right child, and so on - the branch down the tree to the end
129 2012-11-06 01:36:09 <amiller> you check that each piece of node data matches the hash - starting from the root hash, you're guaranteed to have the hash of the next piece of data you're expecitng
130 2012-11-06 01:36:25 <amiller> on the way down to the leaf, you put the node data in a stack because you're going to need it again on the way back up the tree
131 2012-11-06 01:37:00 <amiller> when you get to the leaf, you can check that you're not inserting a duplicate element, and you have all the data in your stack you need to compute the new root hash
132 2012-11-06 01:37:41 <etotheipi_> so you're talking about dynamically downloading from peers, the data you need to do full validation, as you find out you need it (as opposed to having it all on hand)
133 2012-11-06 01:37:42 <etotheipi_> ?
134 2012-11-06 01:38:16 <amiller> yes, that's what i call an O(1)-storage full validating client
135 2012-11-06 01:38:32 <amiller> but if you have m < M amount of memory, you sohuld store as much validation yourself as you can and make the best use of it
136 2012-11-06 01:39:09 <amiller> instead of just downloading a block from a peer, you download a block + a validation support kit
137 2012-11-06 01:39:56 <etotheipi_> okay, now your original thing about "identifying the next time a node owuld be updated"
138 2012-11-06 01:39:59 <etotheipi_> makes sense
139 2012-11-06 01:40:16 <etotheipi_> I just didn't realize this was a problem we were solving...
140 2012-11-06 01:40:27 <etotheipi_> it's a good problem to solve, I just had never thought about it
141 2012-11-06 01:40:38 <etotheipi_> you've clearly been thinking about this stuff a lot more than me :)
142 2012-11-06 01:40:46 <amiller> the best name for this problem is "batch transaction validation"
143 2012-11-06 01:41:00 <amiller> and it is _THE_ problem to solve (this is perhaps a good time to debate that though!)
144 2012-11-06 01:41:25 <amiller> batch transaction validation is what you need to do to catch up if you've been asleep for a while, it's what you need to do to catch up from a checkpoint in the distant past, including a backup you created for yourself
145 2012-11-06 01:41:32 <etotheipi_> to allow mining to continue by laymen even when UTXO tree gets too huge for most?
146 2012-11-06 01:41:47 <etotheipi_> err... full validation
147 2012-11-06 01:41:59 <amiller> yes precisely
148 2012-11-06 01:42:09 <amiller> it's also what you need to do to deal with a proposed fork
149 2012-11-06 01:42:35 <amiller> most of all, it's what's needed for responsible mining
150 2012-11-06 01:42:38 <amiller> imagine you're on gpu max
151 2012-11-06 01:42:43 <amiller> and you're just going to pay someone to mine on blocks for you
152 2012-11-06 01:42:48 <amiller> you must not pay them if they mine on an invalid block!
153 2012-11-06 01:42:51 <etotheipi_> btw, I don't know anything about gpu max
154 2012-11-06 01:43:00 <amiller> just say it's outsourced mining
155 2012-11-06 01:43:39 <amiller> you could have a big mining rack at a colocation and you can check up on it by doing full validation on your phone every night
156 2012-11-06 01:44:13 <amiller> but yeah, full validation for lite nodes
157 2012-11-06 01:45:07 <etotheipi_> ambitious, but good
158 2012-11-06 01:46:08 <etotheipi_> okay, so at least we're starting at the same place now
159 2012-11-06 01:46:13 <amiller> phew :D
160 2012-11-06 01:46:29 <etotheipi_> and just in time for me to leave for 20 min :-/
161 2012-11-06 01:46:31 <amiller> all these months, i had no idea that was where we were differed
162 2012-11-06 01:47:11 <etotheipi_> well you were thinking much further ahead than me
163 2012-11-06 01:47:22 <etotheipi_> or bigger, rather
164 2012-11-06 01:48:01 <etotheipi_> I had only thought about "lite nodes that would like to get their state with the security of downloading the entire history, without actually downloading it", and "full-pruning nodes that maintain the whole tree"
165 2012-11-06 01:48:56 <etotheipi_> I didn't consider your thing even possible (but hadn't even tried to think about it)
166 2012-11-06 01:49:14 <etotheipi_> brb
167 2012-11-06 01:58:21 <da2ce7_d> I just wanted to check with the crypto experts here, is this idea sane: http://pastebin.com/rC3eAe4N
168 2012-11-06 02:00:30 <helo> could a bitcoin-backed currency be created by an organization by issuing btc-denominated bills with the backing bitcoin addresses, with people scanning the bills and checking the backing address's balance when accepting?
169 2012-11-06 02:01:36 <lianj> its not a bitcoin then, just bitcoin backed
170 2012-11-06 02:02:16 <helo> for every-day low-valued cash purchases, it seems like a good way to allow bitcoin to be used widely for everyday transactions without driving fees up
171 2012-11-06 02:02:31 <helo> with actual bitcoin transactions
172 2012-11-06 02:03:04 <xenland> helo: Very possible, already done, cassicus coins, Bitcoin checks, etc
173 2012-11-06 02:03:18 <maaku> helo: you mean like this: http://printcoins.com
174 2012-11-06 02:03:28 <xenland> http://www.youtube.com/watch?v=DR_zDrzhPgE
175 2012-11-06 02:03:41 <helo> hard to buy a hamburger with a cassicus
176 2012-11-06 02:03:46 <xenland> yep
177 2012-11-06 02:03:52 <helo> maaku: not like that, without the private key
178 2012-11-06 02:04:12 <helo> maaku: just a bitcoin address showing that the backing funds have no been moved
179 2012-11-06 02:04:17 <xenland> You need the privatekey, or its just pointless
180 2012-11-06 02:04:24 <maaku> helo: then what's the point?
181 2012-11-06 02:04:33 <helo> the issuing organization issues them and ensures they stay backed
182 2012-11-06 02:04:37 <xenland> Might as well use fiat
183 2012-11-06 02:04:57 <xenland> helo:Bitcoin block chain insures they are backed
184 2012-11-06 02:05:03 <xenland> hence privatekey is needed
185 2012-11-06 02:05:21 <maaku> helo: what's preventing counterfeiting?
186 2012-11-06 02:05:22 <helo> and makes money on small exchange fees when someone wants to exchange the bills for actual btc
187 2012-11-06 02:05:34 <lianj> he means a bitcoin backed token
188 2012-11-06 02:05:36 <helo> maaku: trust in the issuin organization
189 2012-11-06 02:05:40 <helo> issuing
190 2012-11-06 02:05:51 <helo> exactly like a gold-backed paper currency
191 2012-11-06 02:05:52 <xenland> Why exchange bills for actual btc when you have the privatekey to the BTC no need to exchange
192 2012-11-06 02:05:56 <helo> but bitcoin-backed
193 2012-11-06 02:08:02 <helo> generally i think bills like the one below is expected to becone a bitcoin transaction when it is claimed by the receiving party
194 2012-11-06 02:08:18 <helo> *the ones on printbitcoins.com
195 2012-11-06 02:10:37 <helo> we know bitcoin can't completely replace the transaction volumes of major financial institutions because of blockchain space
196 2012-11-06 02:12:49 <amiller> something that's been bugging me a lot very recently is that almost anything you can do with a bitcoin requires a lot of trust in the other party
197 2012-11-06 02:13:12 <xenland> amiller: Bitcoin needs a better Web of trust/rating system seriously
198 2012-11-06 02:13:21 <amiller> except for a face-to-face transaction where you wait an hour before disengaging, in any exchange some party has to go first
199 2012-11-06 02:13:22 <xenland> Invite only Web of trust dosen't work  hehe
200 2012-11-06 02:14:12 <amiller> bitcoin is digital money, in the style of gold
201 2012-11-06 02:14:27 <amiller> and any economist will tell you that money solves an efficiency problem with barter, specifically the "double coincidence of wants"
202 2012-11-06 02:14:37 <amiller> does digital money solve the same problem for digital barter?
203 2012-11-06 02:14:51 <amiller> the problem with digital barter isn't that its inefficient, it's that it's impossible or at least insecure
204 2012-11-06 02:16:11 <vazakl-> digibarter
205 2012-11-06 02:16:47 <amiller> the problem of associating reputation/trust with pseudonyms is more fundamental than the problem money solves, and it's also orthogonal since even perfect money doesn't solve it
206 2012-11-06 02:17:17 <vazakl-> true
207 2012-11-06 02:18:11 <vazakl-> trusting WoT ratings might have 0 benefit.. once someone gets enough rep theyre happy to cash it in for an epic scam (pir8)
208 2012-11-06 02:18:35 <vazakl-> or even a disadvantage (my rep is higher than yours, give me a discount or ill penalize your rating!)
209 2012-11-06 02:21:05 <amiller> i like the idea of a credit graph rather than a ratings graph, since i don't see any way that ratings can't be gamed, but then we're basically talking about ripple (or, effectively, colored coins)
210 2012-11-06 02:22:15 <xenland> a credit graph is a great idea in comaprison then a simple number
211 2012-11-06 04:02:51 <amiller> i wonder if proof-of-work can be used to straight-up solve prisoners dilemma
212 2012-11-06 04:03:28 <amiller> "we are a way for the cosmos to know itself"
213 2012-11-06 04:05:03 <amiller> the blockchain as a whole is a proof-of-work
214 2012-11-06 04:06:14 <amiller> but while individual blocks are embarrassingly parallel, a long chain of blocks isn't - that requires communication
215 2012-11-06 04:06:28 <amiller> communication isn't so hard, at least within a macine or a data center
216 2012-11-06 04:06:33 <amiller> but more than communication, it also requires cooperation
217 2012-11-06 04:07:27 <amiller> it's proof of work that could have been used for something else but wasn't, it's evidentially directed towards a self-reflective process
218 2012-11-06 04:36:38 <xenland> Or stop sending people to prison
219 2012-11-06 04:37:21 <xenland> 1 year of forced education usual outweighs locking someone up for a 1 year
220 2012-11-06 04:37:32 <xenland> problem solved hehe :P
221 2012-11-06 04:39:57 <senseless> i thought that's what electroshock therapy was for
222 2012-11-06 04:40:40 <xenland> heh
223 2012-11-06 04:40:52 <xenland> probubly quicker too
224 2012-11-06 04:56:26 <amiller> the southhampton strategy for iterated prisoners dilemma
225 2012-11-06 04:56:30 <amiller> involves a "self recognition" dance
226 2012-11-06 04:57:14 <amiller> which technically violates the assumption that the prisoners are not allowed to communicate with each other
227 2012-11-06 04:59:11 <andrew12> so when will bitcoin 1.0 release? when it is verified that all of its functions work (e.g. block reward halving)
228 2012-11-06 04:59:14 <andrew12> ?
229 2012-11-06 05:07:31 <xenland> I think Bitcoin is following the usual version number patterns
230 2012-11-06 05:08:08 <xenland> http://en.wikipedia.org/wiki/Software_versioning
231 2012-11-06 05:10:07 <xenland> based off the developers way of speech I think they will make it 1.0 when its ready for mainstream public fancial use, there is some issues stilll like huge block chain makes it harder and harder/longer and longer to verify things in bitcoin
232 2012-11-06 05:10:28 <xenland> well thats kind of fixed now but stuff like that
233 2012-11-06 05:13:06 <robbak> It seems to me to be a rather ugly crock to have two comlpetely different build systems for the qt gui and the CLI daemon. Am I alone there?
234 2012-11-06 05:13:59 <Luke-Jr> they're two different clients
235 2012-11-06 05:14:11 <Luke-Jr> just lacking a proper abstraction layer around the core/shared codebase
236 2012-11-06 05:16:00 <robbak> OK. It is less of an issue now that there is a console on the debug window to run commands on, anyway.
237 2012-11-06 05:28:39 <SupaDupa> something something in the month of may
238 2012-11-06 05:28:47 <SupaDupa> Bitcoiners like my ePenis cause it's REALLY big
239 2012-11-06 05:30:36 <Ssateneth> /popcorn
240 2012-11-06 05:30:49 <SupaDupa> Bitcoiners are only good for 3 things
241 2012-11-06 05:30:53 <SupaDupa> Scamming
242 2012-11-06 05:30:56 <SupaDupa> Thieving
243 2012-11-06 05:31:00 <SupaDupa> and Vaginas
244 2012-11-06 05:31:23 <xIsalty> really supa
245 2012-11-06 05:31:25 <xIsalty> this channel
246 2012-11-06 05:31:30 <xIsalty> back to #btc-e
247 2012-11-06 05:31:38 <SupaDupa> lol
248 2012-11-06 05:31:38 <xIsalty> Im watching
249 2012-11-06 05:31:47 <SupaDupa> Bitcoiners are stupid
250 2012-11-06 05:31:51 <SupaDupa> and I don't respect them
251 2012-11-06 05:31:53 <Ssateneth> like you
252 2012-11-06 05:31:56 <SupaDupa> I just scam them
253 2012-11-06 05:32:05 <SupaDupa> you're talking to me about stuff
254 2012-11-06 05:32:07 <SupaDupa> why?
255 2012-11-06 05:32:13 <SupaDupa> I'd much rather see the bitcoins
256 2012-11-06 05:32:28 <SupaDupa> that's right bitch
257 2012-11-06 05:32:31 <SupaDupa> now open your wallet
258 2012-11-06 05:32:36 <SupaDupa> and show me your bitcoins
259 2012-11-06 05:51:05 <phantomcircuit> jgarzik, plz2bansupadupa
260 2012-11-06 05:58:31 <SupaDupa> why for to make ban me?
261 2012-11-06 06:01:59 <Detritus> your trollfu is weak
262 2012-11-06 06:15:32 <SupaDupa> stfu and sell me bitcoins Detritus
263 2012-11-06 06:17:38 <SomeoneWeird> no u
264 2012-11-06 06:20:09 <SupaDupa> the fuck
265 2012-11-06 06:20:25 <SupaDupa> why would I want bitcoins if I had bitcoins to sell
266 2012-11-06 06:21:32 <SupaDupa> gtfo wizkid
267 2012-11-06 06:21:36 <SupaDupa> you arn't a dev
268 2012-11-06 06:21:45 <SupaDupa> ya fuckin right read error
269 2012-11-06 06:21:49 <SupaDupa> you are bad at reading
270 2012-11-06 06:22:06 <wizkid057> 
ACTION tries to kickban...

271 2012-11-06 06:22:54 <xIsalty> lol
272 2012-11-06 06:23:14 <SupaDupa> haha can't do
273 2012-11-06 06:23:15 <SupaDupa> muhahahha
274 2012-11-06 06:23:18 <SupaDupa> stupid non dev
275 2012-11-06 06:23:29 <SupaDupa> 
ACTION points and laughs at wizkid057

276 2012-11-06 06:24:09 <xIsalty> I have a bet for bitcoin-devs, I bet that you cant build the gui version of bitcoin on windows, and if you can well done :-D.
277 2012-11-06 06:24:29 <wizkid057> isnt their already a windows GUI ? :P
278 2012-11-06 06:24:40 <SupaDupa> he means build from source
279 2012-11-06 06:24:45 <SupaDupa> you can't do cause you scrub
280 2012-11-06 06:24:46 <xIsalty> you cant build it yourself
281 2012-11-06 06:24:50 <SupaDupa> he's calling you one
282 2012-11-06 06:24:53 <xIsalty> its hard work
283 2012-11-06 06:25:08 <xIsalty> which is why the dev team gave up on it
284 2012-11-06 06:25:17 <xIsalty> uses nix from now
285 2012-11-06 07:14:51 <sipa> amiller, etotheipi_: can we schedule a point in time to discuss authenticated utxo sets, which doesn't require me to wake up at night? (i.e., before 1am cest)
286 2012-11-06 07:17:30 <sipa> oh, cet now
287 2012-11-06 07:19:58 <sipa> xIsalty: most important reason is that no core devs use windows, and gitian uses cross-compilation
288 2012-11-06 07:20:18 <xIsalty> is it easier
289 2012-11-06 07:20:50 <sipa> what easier than what?
290 2012-11-06 07:21:07 <xIsalty> building on windows
291 2012-11-06 07:21:27 <sipa> you haven't answered my question
292 2012-11-06 07:21:33 <xIsalty> oh sorry
293 2012-11-06 07:21:44 <xIsalty> is cross compilation easier than building on windows ?
294 2012-11-06 07:22:45 <sipa> well, since gitian only runs on ubuntu, there is no question of easier... it's just the only option for the release binaries
295 2012-11-06 07:23:25 <xIsalty> fair enough
296 2012-11-06 07:23:56 <sipa> and because of that, only the cross-compilation part is maintained
297 2012-11-06 08:06:03 <xenland> Whats the command to ping my Bitcoin node to send me X amount of blocks?
298 2012-11-06 08:19:02 <sipa> xenland: getblocks will make it reply with a list of blocks it knows
299 2012-11-06 08:19:19 <sipa> xenland: getdata is then issued for each that isn't known yet
300 2012-11-06 08:23:39 <xenland> sipa: thanks mate
301 2012-11-06 09:02:46 <abrkn> anyone know an escrower online?
302 2012-11-06 09:02:50 <abrkn> damn timezones
303 2012-11-06 10:54:11 <robbak> dev q: I've got a small change that I'd like to have looked at.
304 2012-11-06 10:54:34 <robbak> Where the make file tries to make leveldb, it hardcodes the make command line.
305 2012-11-06 10:54:52 <robbak> FreeBSD tries to use the stock make, which fails. It needs to run gmake.
306 2012-11-06 10:55:15 <robbak> This is all sorted out if you use $(MAKE) in the coded line.
307 2012-11-06 10:55:48 <robbak> If that will not cause problems for other un*cies, should it be done?
308 2012-11-06 11:05:40 <robbak> I've got a pull waiting for me to click on the send button, if it is worth it.
309 2012-11-06 11:07:02 <sipa> robbak: if you submit it, matt's pulltester will try building
310 2012-11-06 11:07:18 <sipa> if it doesn't break anything on supported platforms, i have no problem merging
311 2012-11-06 11:08:37 <robbak> OK, I'll give it a shot. Test build just finished happily, and the test program runs error free. Let's see what happens.
312 2012-11-06 13:57:03 <[MOFO]> ur fuckin gay
313 2012-11-06 13:57:07 <[MOFO]> jeff garzik
314 2012-11-06 14:02:47 <jgarzik> for SupaDupa
315 2012-11-06 17:39:31 <jgarzik> huh
316 2012-11-06 17:39:41 <jgarzik> my detect-incoming-payment code works after all
317 2012-11-06 17:39:45 <jgarzik> it was the test that was broken
318 2012-11-06 17:51:03 <maaku> beware: Virtual machine used to steal crypto keys from other VM on same server: http://arstechnica.com/security/2012/11/crypto-keys-stolen-from-virtual-machine/
319 2012-11-06 17:53:23 <drizztbsd> maaku: is kvm vulnerable?
320 2012-11-06 17:53:45 <_dr> 'in which attackers crack a private key by studying the electromagnetic emanations' whatnow?!
321 2012-11-06 17:54:17 <drizztbsd> like the xbox360 glitch hack :P
322 2012-11-06 17:55:07 <maaku> The paper used Xen, but unless KVM specifically protects against this, it'd be vulnerable too
323 2012-11-06 17:55:54 <_dr> i think it's a hoax
324 2012-11-06 17:56:29 <maaku> _dr: it's a published paper that passed peer review; do you have a reason to think it's a hoax or are you trolling
325 2012-11-06 17:57:08 <_dr> maaku: from this short synopsis i'd say its a hoax
326 2012-11-06 17:57:40 <_dr> how can you get 'fragments of the cryptographic(?) square and multiply function' just by looking at what cache lines get evicted from cache
327 2012-11-06 18:00:14 <maaku> Read the paper; there's a whole section on that: http://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
328 2012-11-06 18:00:17 <_dr> ok, it's kind of a xen bug
329 2012-11-06 18:00:21 <_dr> http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html
330 2012-11-06 18:01:28 <maaku> It's not a bug, unless by bug you mean "xen doesn't automatically kill performance by clearing the cache on each process switch"
331 2012-11-06 18:01:54 <abrkn> anyone able to send some testnet btc?
332 2012-11-06 18:02:22 <abrkn> mwbQ9LRrWtW1gaXNyReKmdJ5M7FjzBHeKr
333 2012-11-06 18:02:26 <_dr> maaku: not that part. i mean the part where you can preempt other vcpus
334 2012-11-06 18:03:38 <abrkn> faucet is down...
335 2012-11-06 18:03:38 <_dr> but it's amazing they can determing which of their level1 instruction cache data has been preempted
336 2012-11-06 18:04:40 <maaku> _dr: it doesn't preempt other vcpus. it's just normal process scheduling
337 2012-11-06 18:05:18 <_dr> maaku: yes it does, they use a dedicated vpu that issues interrupts (which in turn makes xen give priority to their other vcpu)
338 2012-11-06 18:05:50 <_dr> because they have to regain the cpu pretty fast from the victims vcpu
339 2012-11-06 18:06:02 <abrkn> gentlemen... anyone able to send some testnet money?
340 2012-11-06 18:06:43 <maaku> that increases signal-to-noise, but the side-channel attack still exists
341 2012-11-06 18:07:26 <_dr> but kinda with p_success = 0
342 2012-11-06 18:08:09 <_dr> otherwise the other vcpu will preempt all instruction data from the level one instruction cache (which is about 32kb), then no attack is possible
343 2012-11-06 18:08:53 <_dr> doesn't change that fact that the attack is pretty ingenious :)
344 2012-11-06 18:09:46 <maaku> not necessarily--there's a long tail of situations where natural interrupts occur (incoming network packets, for example), and the attacking vm only has to keep priming the cache and waiting
345 2012-11-06 18:10:09 <drizztbsd> I can register to linode and sniff bitcoin keys :P
346 2012-11-06 18:10:40 <_dr> drizztbsd: the attack is pretty much tailored for elgamal
347 2012-11-06 18:11:08 <drizztbsd> but it's not impossible
348 2012-11-06 18:11:15 <maaku> and for high-use keys
349 2012-11-06 18:11:30 <maaku> you need to observe many signatures before you reconstruct
350 2012-11-06 18:11:53 <_dr> makes me wonder why such attacks haven't been done earlier
351 2012-11-06 18:12:12 <_dr> i assume you can just allocate huge chunks of memory and search them for 'high entropy'
352 2012-11-06 18:13:09 <drizztbsd> entropy used to generate the key
353 2012-11-06 18:13:17 <_dr> or do you guys memset with zero before free ;)
354 2012-11-06 18:13:46 <drizztbsd> lol maybe openssl does it
355 2012-11-06 18:24:34 <uvelol> Hi! I can't understand, who creates task for bitcoin miners?
356 2012-11-06 18:24:51 <_dr> does bitcoin? addresses should be easily detectable in memory
357 2012-11-06 18:25:27 <sipa> uvelol: in mining pools, the pools; otherwise typically a local bitcoind
358 2012-11-06 18:25:59 <uvelol> sipa: and who gives tasks to those pools?
359 2012-11-06 18:26:35 <sipa> nobody
360 2012-11-06 18:26:43 <uvelol> as far as I understand, bitcoin is global, but decentralised? Am I right?
361 2012-11-06 18:26:47 <sipa> yes
362 2012-11-06 18:27:19 <sipa> they choose their own work, basically
363 2012-11-06 18:27:29 <sipa> and cryptography is used to prove they did the work
364 2012-11-06 18:27:52 <uvelol> So, I can create my pool which will be solving travelling salesman problem?
365 2012-11-06 18:28:08 <sipa> no
366 2012-11-06 18:28:29 <sipa> the problem is "low hash resulting from double-sha256'ing contructed block header"
367 2012-11-06 18:30:35 <uvelol> http://blockexplorer.com/ and these are ALL the transactions of the whole bitcoin system listed?
368 2012-11-06 18:31:42 <uvelol> and >Total BTC means that someone has sent to another person 4145 bitcoins or 41450 dollars?
369 2012-11-06 18:33:57 <_dr> not neccessarily. it means that the last block records N transactions, in which 4145 bitcoins have changed addresses/'owners'
370 2012-11-06 18:33:58 <uvelol> And what if someone gets 500,000 bitcoins and then sinks his or her hard drive in acid?
371 2012-11-06 18:34:18 <_dr> then they're gone if he didn't back up his wallet
372 2012-11-06 18:34:31 <uvelol> _dr: But there is limited amount of bitcoins.
373 2012-11-06 18:35:00 <uvelol> Will that mean that there are now only 20.5 million bitcoins total possible?
374 2012-11-06 18:35:10 <_dr> yes
375 2012-11-06 18:38:37 <uvelol> uh, and what if two miners, one in UK, another in USA got the same task in different bitcoin pools and solved it simultaneously?
376 2012-11-06 18:42:13 <_dr> uvelol: see paragraph 4 https://en.bitcoin.it/wiki/Block_chain
377 2012-11-06 18:48:55 <uvelol> So, if I understand correctly, I can now about all payments that were made to some person P if I know his wallet number?
378 2012-11-06 18:54:51 <D34TH> whats the best pushpool right now
379 2012-11-06 18:55:09 <_dr> uvelol: a wallet has multiple addresses
380 2012-11-06 18:55:31 <_dr> basically, if i sell something to you, and you sent money to my address you know my address
381 2012-11-06 18:55:56 <_dr> but i can generate a new address, send my money there and you wouldn't know whom the new address belongs to
382 2012-11-06 18:58:04 <uvelol> _dr: but you will have to use your new address in future. and then I will be able to see where you've transfered that money that I've sent to you. Is it true?
383 2012-11-06 18:59:16 <_dr> uvelol: but how can you know that I own that new address? maybe i've bought something and the address belongs to someone else
384 2012-11-06 18:59:48 <_dr> all you can see is that the money you to my address is going to some new address
385 2012-11-06 19:05:35 <uvelol> _dr: so, if I owned some address A, and some FBI guys were interested in catching me, and I transfered Btc from wallet A to another wallet A1, then from A1 to A2, .... to An and then bought pizza delivery with my An wallet, than I would be caught?
386 2012-11-06 19:11:09 <helo> uvelol: yes, because they'd have a trojan installed on your machine, and would know all of your addresses
387 2012-11-06 19:11:37 <helo> or no, because they couldn't link the addresses to you
388 2012-11-06 19:12:04 <gavinandresen> is it illegal to buy pizza where you are?
389 2012-11-06 19:13:18 <uvelol> gavinandresen: no, I'm thinking about the problem when you have a public wallet, which is compromised and you have to convert your bitcoins to something real without being caught
390 2012-11-06 19:13:56 <gavinandresen> lots of people have thought about that problem; see all of the threads in the bitcointalk forums about 'washing' or 'laundering' bitcoins
391 2012-11-06 19:14:25 <gavinandresen> there are even some services that say they'll wash your coins for you.  Some of them are probably not even scams....
392 2012-11-06 19:15:10 <gavinandresen> And note that we don't claim that bitcoin is anonymous, just that you can get good privacy if you work really hard at it.
393 2012-11-06 19:36:00 <maaku> uvelol: if you want anonymity, you're better off not using the block chain; maybe use double-blinded untraceable tokens from Open-Transactions backed by bitcoins, or a multi-user online wallet that doesn't keep logs
394 2012-11-06 19:37:10 <D34TH> wow, i just wasted alot of work
395 2012-11-06 19:37:17 <D34TH> trying to setup poolserverj for testnet
396 2012-11-06 19:37:24 <D34TH> turns out getblocknumber doesnt exist
397 2012-11-06 19:41:00 <BlueMatt> gavinandresen: wait...when was the time for the meetings decided on...?
398 2012-11-06 19:55:12 <topace> from the api, is there a way to get the address that the coins came FROM? (eg, so i can send something back to the address? like satoshi dice does?)
399 2012-11-06 19:59:35 <uvelol> Is god able to solve the halting problem??
400 2012-11-06 20:00:46 <helo> he'll get back to you real soon now
401 2012-11-06 20:05:22 <uvelol> Well, and if the halting problem was solvable in linear time, then TDD would be the only approach to software developing.
402 2012-11-06 20:06:07 <gmaxwell> uvelol: the halting problem is often solvable in linear time. It's not always solvable at all.
403 2012-11-06 20:17:23 <uvelol> gmaxwell: But the most interesting cases are when it's not solvable at all. I just can't imagine how would the world change. But are there such theorems that won't be proved or refuted if the haltingproblem was solvable?
404 2012-11-06 20:17:31 <helo> #bitcoin question regarding a data-hungry peer
405 2012-11-06 20:20:42 <maaku> uvelol: not necessarily. there are few if any practical programs that cannot be re-factored into a form that are solvable in a reasonable amount of time
406 2012-11-06 20:21:10 <maaku> err, i mean halting problem can be solved in a reasonable amount of time
407 2012-11-06 20:22:03 <maaku> singularity/midori is moving in that direction, slowly
408 2012-11-06 20:23:11 <uvelol> maaku: how can midori/singularity help us in halting problem?
409 2012-11-06 20:24:34 <maaku> it's moving in the direction of the entire software stack from apps to OS/drivers is managed code with provable properties, of which a halting proof would be one example
410 2012-11-06 20:26:35 <maaku> in singularity an executable is required to present a set of proofs in order to run. right now those proofs only have to do with memory and type correctness, but a halting proof would fit in that model
411 2012-11-06 20:27:10 <uvelol> maaku: so how would I launch md5 bruteforcing in singularity?
412 2012-11-06 20:27:57 <uvelol> (if a halting proof is required)
413 2012-11-06 20:28:33 <copumpkin> types can capture all sorts of correctness
414 2012-11-06 20:28:37 <uvelol> like, if I launched a bruteforcer to seek for such a string that results into all zeroes md5 digest.
415 2012-11-06 20:28:47 <copumpkin> including termination
416 2012-11-06 20:30:48 <maaku> uvelol: you run a brute-forcer that tries a billion hashes and then terminates with error if a match hasn't been found
417 2012-11-06 20:31:03 <maaku> you can prove that terminates
418 2012-11-06 20:31:24 <uvelol> of course, but what if we don't know the limit?
419 2012-11-06 20:31:25 <maaku> not unlike the way bitcoin miners are actually structured
420 2012-11-06 20:31:57 <maaku> i don't understand the question--the os execution time limit would be well known
421 2012-11-06 20:32:40 <uvelol> I don't understand it either.
422 2012-11-06 20:33:55 <maaku> the requirement in a halting-proof is that program execution finishes--but that doesn't mean the program must terminate or a solution must be found
423 2012-11-06 20:36:18 <maaku> a program could be in an infinite loop waiting on a socket for new data as long as what it does with that data finishes in finite time, or you can batch something like checking for hash collisions so it finishes after X iterations whether it found something or not
424 2012-11-06 20:37:22 <helo> it's trivial to create an example of a program that does halt
425 2012-11-06 20:37:24 <maaku> An inability to prove that a program won't get stuck in an infinite loop somewhere is usually a sign of bad software design, or avoidable through good design. Having the OS enforce good software design is not a bad thing ;)
426 2012-11-06 20:37:56 <uvelol> yeah, I totally understand what you mean. But I wanted to understand how would people live if all theorems were checkable.
427 2012-11-06 20:38:29 <helo> if you didn't want to set an upper-bound on the number of iterations, your program i guess would refuse to run?
428 2012-11-06 20:39:39 <maaku> helo: the os would refuse to run your program, yes
429 2012-11-06 20:41:01 <jgarzik> wow
430 2012-11-06 20:41:05 <jgarzik> merkle branch stuff was easy
431 2012-11-06 20:43:55 <aurigae> can anybody tell me what "onion winners" is in stats.php on simplecoin
432 2012-11-06 20:45:53 <aurigae> https://github.com/simplecoin/simplecoin/blob/master/stats.php
433 2012-11-06 20:50:27 <jgarzik> 
ACTION waits for gmaxwell to mock this thread, https://bitcointalk.org/index.php?topic=122632.0 "bitcoind security best practices?"

434 2012-11-06 20:50:32 <jgarzik> It's an honest question, though
435 2012-11-06 20:50:44 <jgarzik> A "bitcoin secure best practices" guide would be wonderful
436 2012-11-06 20:51:37 <uvelol> jgarzik: hey, I'm not very good at lurking in source code, but what are the root servers, from which bitcoin starts downloading data after clean install?
437 2012-11-06 20:51:51 <maaku> jgarzik: isn't that something the foundation is supposed to provide?
438 2012-11-06 20:52:00 <uvelol> and what if those root servers are down?
439 2012-11-06 20:52:19 <kjj_> there are no root servers, no
440 2012-11-06 20:52:29 <maaku> uvelol: there are no root servers, but you'll find a set of default peers in net.cpp
441 2012-11-06 20:54:23 <kjj_> do you mean the DNS seeds?
442 2012-11-06 20:54:49 <uvelol> maaku: bitcoin.sipa.be so this is one of the "root" servers?
443 2012-11-06 20:55:15 <kjj_> there are no root servers, none.
444 2012-11-06 20:55:20 <maaku> uvelol: there are no root servers!
445 2012-11-06 20:55:42 <maaku> `dig bitcoin.sipa.be` will return the IP address of a random bitcoin peer currently on the network
446 2012-11-06 20:55:44 <kjj_> there are some DNS servers in the code that a node can query to get some nodes to connect to if they have nothing else
447 2012-11-06 20:56:13 <maaku> kjj_: there's also a list of IP addresses that are tried as well, in case the DNS servers are down
448 2012-11-06 20:56:16 <kjj_> once you connect to a node, that node will tell you about other nodes
449 2012-11-06 20:57:54 <kjj_> it only does that if you disable dnsseeds, don't enable IRC seeds, and have never connected to anything ever
450 2012-11-06 21:00:10 <uvelol> kjj_: but why aren't there anyone on #bitcoinDD on irc.lfnet.org?
451 2012-11-06 21:00:23 <maaku> because IRC seeding is disabled by default
452 2012-11-06 21:06:13 <uvelol> maaku: But if these servers are down, the system won't be able to work.
453 2012-11-06 21:06:28 <uvelol> So it can't be called fully decentralized?
454 2012-11-06 21:06:41 <maaku> look up the --connect option
455 2012-11-06 21:06:51 <kjj_> well, there has to be SOME way to make an initial connection.
456 2012-11-06 21:06:54 <maaku> you can always seed it yourself if you know an IP
457 2012-11-06 21:07:25 <kjj_> you'll find that all p2p systems always have some way to bootstrapping new nodes
458 2012-11-06 21:07:40 <uvelol> kjj_: and netsukuku?
459 2012-11-06 21:09:15 <kjj_> what about it?
460 2012-11-06 21:09:58 <uvelol> don't know, is it an unsolvable problem to build a truly distributed network?
461 2012-11-06 21:10:23 <uvelol> Like a halting problem...
462 2012-11-06 21:11:02 <sipa> there are some theorms about that, yes
463 2012-11-06 21:11:08 <kjj_> looks like Netsukuku is about building a mesh of locally connected peers
464 2012-11-06 21:16:13 <maaku> uvelol: you could always try IP addresses at random
465 2012-11-06 21:16:54 <maaku> but practically speaking, it doesn't really matter
466 2012-11-06 21:17:23 <maaku> use an onion seed if you're worried about protocol suppression
467 2012-11-06 21:19:49 <uvelol> maaku: could you say, which states aren't reachable from your current state with time lapse of 10 seconds?
468 2012-11-06 21:20:25 <uvelol> for example, flying in the sky state isn't reachable because you won't be able to catch a heli or invent antigravity in 10 seconds
469 2012-11-06 21:21:13 <uvelol> Travelling to Mars is also doubtfull because of speed of light
470 2012-11-06 21:22:07 <uvelol> Well, I hope that after death I will see such a program that draws all possible traces of a human being.
471 2012-11-06 21:22:52 <uvelol> That's like uh.. halting problem?
472 2012-11-06 21:24:11 <midnightmagic> uh.
473 2012-11-06 21:24:17 <midnightmagic> anyone else have any issue with block 206679 ?
474 2012-11-06 21:24:40 <uvelol> midnightmagic: what's with block 206679?
475 2012-11-06 21:24:54 <midnightmagic> uvelol: I have no idea. "Displayed transactions may not be correct"
476 2012-11-06 21:25:38 <forrestv> midnightmagic, maybe your database is corrupt?
477 2012-11-06 21:26:32 <midnightmagic> forrestv: that's possible. But if someone else had a halting issue at that same block, then I figured perhaps I can just truncate the blk* files and rebuild the blk index.
478 2012-11-06 21:26:51 <midnightmagic> geh.. really not looking forward to a blk* rebuild again..
479 2012-11-06 21:42:45 <rdponticelli_> sipa: I'm pretty sure there's some bug on the transactions accepting logic on ultraprune
480 2012-11-06 21:43:16 <rdponticelli_> I keep seen lots of: 'ERROR: CTxMemPool::accept() : inputs already spent' on my ultraprune nodes
481 2012-11-06 21:46:10 <rdponticelli_> And none of that on the stable ones
482 2012-11-06 21:47:49 <rdponticelli> sipa: And the number of stored orphans on ultraprune is always way larger than on stable
483 2012-11-06 21:48:39 <rdponticelli> Most of the conflicting tx seems to be sdice's
484 2012-11-06 21:50:49 <rdponticelli> One of those transactions was accepted by my ultraprune node, and a couple of blocks after that was received again and stored
485 2012-11-06 21:52:15 <rdponticelli> On the stable one, it was accepted and never saw again
486 2012-11-06 23:01:53 <sipa> rdponticelli: well, the old code had some logic to disable outputting errors for mempool transactions, and ultraprune doesn't
487 2012-11-06 23:02:03 <sipa> so the reporting of errors is understandable
488 2012-11-06 23:02:43 <sipa> also, a transaction being accepted again is interesting... i didn't expect that to be a problem, but maybe we need to keep a list of recently included transactions and shun those from the mempool
489 2012-11-06 23:03:40 <rdponticelli> Yeah, maybe no a big problem
490 2012-11-06 23:04:10 <rdponticelli> If it was orphaning legit transactions it won't be good
491 2012-11-06 23:04:36 <rdponticelli> But it looks like it's just orphaning already accepted transactions
492 2012-11-06 23:06:37 <sipa> that should probably be dealt with
493 2012-11-06 23:06:58 <sipa> it's not an actual problem, but it limits the usefulness of the orphan pool for other transactions
494 2012-11-06 23:21:10 <rdponticelli> Yeah, the orphan pool is indeed growing a lot on ultraprunes