1 2012-06-03 00:00:22 <sipa> you just look at a particular generation time, and see what security it gives you
   2 2012-06-03 00:01:11 <etotheipi_> so it's just giving you more flexibility to find your "sweet spot" instead of having to +4x or -4x compute time
   3 2012-06-03 00:01:21 <sipa> yes
   4 2012-06-03 00:01:40 <Matt_von_Mises> Has anyone found a point to OP_CODESEPARATOR yet?
   5 2012-06-03 00:01:53 <etotheipi_> (sorry, as you can tell, I still didn't fully absorb your gist equations :-/)
   6 2012-06-03 00:02:03 <sipa> Matt_von_Mises: it's historical, and it's deemed unusable now
   7 2012-06-03 00:02:34 <sipa> Matt_von_Mises: originally the scriptSig and scriptPubKey were concatenated with a code separator in between, and then evaluated in one go
   8 2012-06-03 00:02:42 <Matt_von_Mises> Without it I guess signing a transaction would only need the output's hash and index.
   9 2012-06-03 00:03:49 <sipa> ?
  10 2012-06-03 00:04:02 <sipa> signing a transaction is quite a bit more complex than that
  11 2012-06-03 00:04:26 <Matt_von_Mises> I mean it would only need the output's hash and index and not the sub script.
  12 2012-06-03 00:04:45 <Matt_von_Mises> Since the hash and index is related to a particular script anyway.
  13 2012-06-03 00:04:54 <Matt_von_Mises> Or have I not looked at this properly yet?
  14 2012-06-03 00:06:00 <sipa> i'm not following really, but i'm not familiar with the exact details of transaction signing either
  15 2012-06-03 00:09:54 <Matt_von_Mises> Transaction signing seems complicated but I think it will be simple once I get all the information together.
  16 2012-06-03 00:10:03 <Matt_von_Mises> It's what I'm looking at now.
  17 2012-06-03 00:10:06 <sipa> i think it will remain complicated :)
  18 2012-06-03 00:11:04 <Matt_von_Mises> Hindsight will tell.
  19 2012-06-03 00:12:20 <etotheipi_> Matt... OP_CHECKSIG is like the most complicated part about Bitcoin
  20 2012-06-03 00:12:52 <etotheipi_> in hindsight, the *process* kinda makes sense... but the implementation is still nasty no matter how you do it
  21 2012-06-03 00:13:27 <etotheipi_> Matt_von_Mises: in case you never saw it, I documented OP_CHECKSIG pretty thoroughly here:  https://bitcointalk.org/index.php?topic=29416.0
  22 2012-06-03 00:13:43 <etotheipi_> (a few posts down from the top
  23 2012-06-03 00:15:06 <Matt_von_Mises> etotheipi_: I've already got it open in my browser. It's helpful. :-) I'll need to do both transaction signing and signature checking with OP_CHECKSIG. The hash codes make it a bit more awkward but I'll just follow it through and I'm sure it will be fine.
  24 2012-06-03 00:16:21 <etotheipi_> well, it's basically the same thing for both signing and verification...  just watch out for the endianness
  25 2012-06-03 00:17:18 <Matt_von_Mises> Well I hope I got the endianness right with the serialisation code I've already done for the transactions.
  26 2012-06-03 00:20:41 rdponticelli has joined
  27 2012-06-03 00:20:56 <Matt_von_Mises> I did commit what I did for the serialisation. The tests that I've done work: https://github.com/MatthewLM/cbitcoin/blob/master/cbitcoin/test/testCBTransaction.c I'm assuming that the tests are actually correct as well. When I dod the validation and signing I'll have to test real transaction data.
  28 2012-06-03 00:21:02 darkee has joined
  29 2012-06-03 00:24:43 darkee has quit (Ping timeout: 276 seconds)
  30 2012-06-03 00:28:19 minimoose has joined
  31 2012-06-03 00:28:46 Ken` has quit (Ping timeout: 265 seconds)
  32 2012-06-03 00:29:03 Ken` has joined
  33 2012-06-03 00:35:24 Zarutian has joined
  34 2012-06-03 00:37:03 gfinn has quit (Ping timeout: 276 seconds)
  35 2012-06-03 00:39:22 Skaag_ has joined
  36 2012-06-03 00:39:44 Skaag has quit (Read error: Connection reset by peer)
  37 2012-06-03 00:39:44 Skaag_ is now known as Skaag
  38 2012-06-03 00:40:02 wasabi1 has quit (Read error: Connection reset by peer)
  39 2012-06-03 00:42:14 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
  40 2012-06-03 00:42:41 tower has joined
  41 2012-06-03 00:44:38 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
  42 2012-06-03 00:48:38 gfinn has joined
  43 2012-06-03 00:51:36 spiborg has quit (Read error: Connection reset by peer)
  44 2012-06-03 01:02:15 da2ce726 is now known as da2ce7
  45 2012-06-03 01:11:52 toffoo has quit ()
  46 2012-06-03 01:18:01 <Matt_von_Mises> From what I can tell SIGHASH_SINGLE makes other output scripts blank but maintains the VarInt for the scripts?
  47 2012-06-03 01:21:37 brwyatt is now known as brwyatt|Away
  48 2012-06-03 01:21:49 one_zero has joined
  49 2012-06-03 01:22:22 Z0rZ0rZ0r has joined
  50 2012-06-03 01:26:52 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
  51 2012-06-03 01:44:07 Matt_von_Mises has quit (Quit: Leaving.)
  52 2012-06-03 01:47:49 rdponticelli has quit (Ping timeout: 245 seconds)
  53 2012-06-03 01:49:16 graingert has quit (Read error: Connection reset by peer)
  54 2012-06-03 02:01:26 darkskiez2 has quit (Ping timeout: 248 seconds)
  55 2012-06-03 02:01:59 darkskiez2 has joined
  56 2012-06-03 02:06:09 hnz has quit (Ping timeout: 245 seconds)
  57 2012-06-03 02:09:14 t7 has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
  58 2012-06-03 02:25:26 knotwork_ has joined
  59 2012-06-03 02:27:48 knotwork has quit (Ping timeout: 252 seconds)
  60 2012-06-03 02:32:19 _W_ has quit (Excess Flood)
  61 2012-06-03 02:32:25 knotwork__ has joined
  62 2012-06-03 02:32:37 _W_ has joined
  63 2012-06-03 02:34:23 knotwork_ has quit (Ping timeout: 248 seconds)
  64 2012-06-03 02:34:54 skeledrew has quit (Ping timeout: 245 seconds)
  65 2012-06-03 02:37:24 slush has quit (Read error: Connection reset by peer)
  66 2012-06-03 02:37:42 knotwork__ is now known as knotwork
  67 2012-06-03 02:38:23 danbri has joined
  68 2012-06-03 02:39:15 slush has joined
  69 2012-06-03 02:39:32 rdponticelli has joined
  70 2012-06-03 02:40:33 slush has quit (Read error: Connection reset by peer)
  71 2012-06-03 02:43:33 [7] has quit (Disconnected by services)
  72 2012-06-03 02:43:40 TheSeven has joined
  73 2012-06-03 02:44:30 tyn has joined
  74 2012-06-03 02:47:17 knotwork_ has joined
  75 2012-06-03 02:49:54 knotwork has quit (Ping timeout: 245 seconds)
  76 2012-06-03 02:58:58 slush has joined
  77 2012-06-03 03:02:56 <luke-jr> TD[gone]: how can I contact YouTube people?
  78 2012-06-03 03:04:48 slush has quit (Read error: Connection reset by peer)
  79 2012-06-03 03:05:01 Z0rZ0rZ0r has quit (Read error: Operation timed out)
  80 2012-06-03 03:05:48 Z0rZ0rZ0r has joined
  81 2012-06-03 03:07:24 slush has joined
  82 2012-06-03 03:09:32 slush has quit (Read error: Connection reset by peer)
  83 2012-06-03 03:15:36 slush has joined
  84 2012-06-03 03:22:11 danbri_ has joined
  85 2012-06-03 03:24:31 danbri has quit (Ping timeout: 248 seconds)
  86 2012-06-03 03:34:15 danbri_ has quit (Remote host closed the connection)
  87 2012-06-03 03:40:29 slush has quit (Read error: Connection reset by peer)
  88 2012-06-03 03:43:22 slush has joined
  89 2012-06-03 03:58:58 Joric has quit ()
  90 2012-06-03 03:59:32 Joric has joined
  91 2012-06-03 03:59:32 Joric has quit (Changing host)
  92 2012-06-03 03:59:32 Joric has joined
  93 2012-06-03 03:59:51 Joric has quit (Client Quit)
  94 2012-06-03 04:00:41 twmz has quit (Ping timeout: 244 seconds)
  95 2012-06-03 04:00:58 Joric has joined
  96 2012-06-03 04:00:59 Joric has quit (Changing host)
  97 2012-06-03 04:00:59 Joric has joined
  98 2012-06-03 04:05:51 slush has quit (Read error: Connection reset by peer)
  99 2012-06-03 04:11:32 slush has joined
 100 2012-06-03 04:13:46 ThomasV has joined
 101 2012-06-03 04:15:42 RainbowDashh has joined
 102 2012-06-03 04:20:31 slush has quit (Read error: Connection reset by peer)
 103 2012-06-03 04:21:45 slush has joined
 104 2012-06-03 04:21:48 slush has quit (Changing host)
 105 2012-06-03 04:21:48 slush has joined
 106 2012-06-03 04:24:53 osmosis has quit (Quit: Leaving)
 107 2012-06-03 04:27:32 osmosis has joined
 108 2012-06-03 04:38:07 osmosis has quit (Remote host closed the connection)
 109 2012-06-03 04:42:18 silp has joined
 110 2012-06-03 04:43:20 silpee has quit (Ping timeout: 260 seconds)
 111 2012-06-03 04:44:02 Zarutian has quit (Quit: Zarutian)
 112 2012-06-03 04:52:00 slush has quit (Read error: Connection reset by peer)
 113 2012-06-03 04:55:26 slush has joined
 114 2012-06-03 05:03:40 <amiller> etotheipi_, first of all i have a general purpose implementation of balanced merkle-trees here https://github.com/amiller/redblackmerkle
 115 2012-06-03 05:05:17 <amiller> you don't need to mess with the stuff like bucket-sort and uniform key space
 116 2012-06-03 05:05:33 <amiller> you simply balance the tree (a 2-3 tree or a redblack tree) each time you insert or delete something
 117 2012-06-03 05:05:45 <amiller> it still takes O(log N) to do either of those
 118 2012-06-03 05:06:53 <amiller> i think that aspect is the only thing missing from yours and gmaxwell's and dthdt's posts about using more merkle trees
 119 2012-06-03 05:08:16 <amiller> i'm still meaning to write a forum post or a wiki or a note to bitcoin-dev summarizing all this but i'm not too sure where to dig in, so if you give me any feedback i'll probably get a bit further along
 120 2012-06-03 05:08:53 <amiller> the point of balancing is that you maintain a strict worst-case bound for how long it takes to verify a tree.
 121 2012-06-03 05:09:43 <amiller> so there's no way for someone to 'congest a portion of tree' the way you described
 122 2012-06-03 05:10:17 <amiller> so there are at least two kinds of useful ways to index this tree
 123 2012-06-03 05:11:24 <amiller> 1) is by txhash/index - if you index it that way, a lite client (a verifier with O(1) of state, i.e. the root hash) can tell if any inputs in a new transaction have already been spent or not.
 124 2012-06-03 05:11:49 <amiller> 2) is by address - if you store them this way, then a lite client can verify its balance at any given time.
 125 2012-06-03 05:12:51 <amiller> i see no reason not to maintain at least two trees, one for each of those useful indexes.
 126 2012-06-03 05:13:26 minimoose has quit (Quit: minimoose)
 127 2012-06-03 05:14:35 <amiller> This stuff is pretty well described in an academic research using the phrase "Authenticated Data Structures" but I don't know of any other implementations
 128 2012-06-03 05:20:39 tyn has quit (Quit: Leaving)
 129 2012-06-03 05:22:35 slush has quit (Read error: Connection reset by peer)
 130 2012-06-03 05:22:38 slush1 has joined
 131 2012-06-03 05:33:36 slush1 has quit (Read error: Connection reset by peer)
 132 2012-06-03 05:53:38 slush has joined
 133 2012-06-03 06:01:08 brwyatt is now known as brwyatt|Away
 134 2012-06-03 06:16:28 JZavala has joined
 135 2012-06-03 06:18:07 slush has quit (Read error: Connection reset by peer)
 136 2012-06-03 06:18:54 slush has joined
 137 2012-06-03 06:19:45 slush has quit (Read error: Connection reset by peer)
 138 2012-06-03 06:22:15 Facefox has quit (Ping timeout: 244 seconds)
 139 2012-06-03 06:23:28 silp has quit (Read error: No route to host)
 140 2012-06-03 06:23:50 silp has joined
 141 2012-06-03 06:26:09 Facefox has joined
 142 2012-06-03 06:29:54 shurnormal has joined
 143 2012-06-03 06:41:05 slush has joined
 144 2012-06-03 06:41:45 RainbowDashh has quit (Quit: RainbowDashh)
 145 2012-06-03 06:51:40 Joric_ has joined
 146 2012-06-03 06:51:47 Joric_ has quit (Changing host)
 147 2012-06-03 06:51:48 Joric_ has joined
 148 2012-06-03 06:54:00 Joric has quit (Ping timeout: 260 seconds)
 149 2012-06-03 06:56:40 D34TH has quit (Ping timeout: 276 seconds)
 150 2012-06-03 06:58:26 Apexseals has quit (Read error: Connection reset by peer)
 151 2012-06-03 06:58:44 Apexseals has joined
 152 2012-06-03 07:01:31 silpee has joined
 153 2012-06-03 07:03:28 silp has quit (Ping timeout: 244 seconds)
 154 2012-06-03 07:03:58 <forrestv> amiller, you're talking about the "flipping the chain" idea?
 155 2012-06-03 07:05:00 <amiller> i don't recognize that phrase?
 156 2012-06-03 07:05:23 <Diablo-D3> oh thats easy
 157 2012-06-03 07:05:30 <Diablo-D3> how about I give you this
 158 2012-06-03 07:05:32 * Diablo-D3 flips the chain
 159 2012-06-03 07:05:37 <Diablo-D3> and you give me my phone call
 160 2012-06-03 07:05:58 * amiller ding dong ding dong ding banana phone
 161 2012-06-03 07:06:09 <Diablo-D3> also, I feel old
 162 2012-06-03 07:06:20 <Diablo-D3> I just realized there are kids out there who were born AFTER the matrix.
 163 2012-06-03 07:06:34 <Diablo-D3> and they might be mining bitcoins.
 164 2012-06-03 07:06:47 <Diablo-D3> kids born AFTER the matrx... mining bitcoins.
 165 2012-06-03 07:06:57 <Diablo-D3> after the matrix, mining bitcoins.
 166 2012-06-03 07:07:13 <Diablo-D3> seriously. what the fuck.
 167 2012-06-03 07:08:50 <amiller> forrestv, i wonder if by 'flipping' you mean making the 'unspent coins database' the primary datastructure in the protocol, instead of the 'blockchain' history?
 168 2012-06-03 07:12:47 Apexseals has quit (Read error: Connection reset by peer)
 169 2012-06-03 07:13:01 Apexseals has joined
 170 2012-06-03 07:13:07 <bd_> not really possible, that. You can't trust another node to compute the transition between states (unspend DBs) correctly, so you need to see the state transitions (blockchain history) to check their work
 171 2012-06-03 07:13:28 <bd_> clients could of course start pruning old txns and just maintain the unspent coins. But the protocol itself needs to remain in terms of txns
 172 2012-06-03 07:13:33 molecular has quit (Read error: Connection reset by peer)
 173 2012-06-03 07:14:15 molecular has joined
 174 2012-06-03 07:14:51 ovidiusoft has joined
 175 2012-06-03 07:16:57 <amiller> ah a great question, bd_
 176 2012-06-03 07:17:07 <amiller> you _can_ trust another node to compute the transition in the unspend DB
 177 2012-06-03 07:17:22 <bd_> not if you never see said txn :)
 178 2012-06-03 07:17:34 <amiller> you need to see the said txn, but you do not need the history
 179 2012-06-03 07:17:45 username57913 has joined
 180 2012-06-03 07:17:45 <amiller> to see why, consider that the unspend DB is a balanced binary search tree
 181 2012-06-03 07:17:54 <amiller> the transitions are always insertions or deletions in the tree
 182 2012-06-03 07:18:10 <amiller> insertions and deletions each only involve touching O(log N) nodes in the worst-case
 183 2012-06-03 07:18:11 <bd_> the representation of the unspent DB isn't really the interesting part, to be honest
 184 2012-06-03 07:18:30 <bd_> bitcoin is a state machine, where state transitions are determined by a distributed consensus protocol
 185 2012-06-03 07:18:47 <bd_> the unspent coin DB is the state, and blocks are state transitions
 186 2012-06-03 07:19:14 <bd_> the distributed consensus protocol must be resistant to byzantine failures, and this makes the whole thing more difficult :)
 187 2012-06-03 07:19:37 <bd_> as I said, nodes can certainly discard their transition log and just keep the current state, after they finish checking the work themselves
 188 2012-06-03 07:19:53 <bd_> however there are limits to this - someone needs a full log to help new nodes bootstrap themselves
 189 2012-06-03 07:20:06 <bd_> and you need to keep enough transactions to be able to back out and replay when the blockchain forks
 190 2012-06-03 07:20:23 <bd_> and, of course, what goes over the wire are blocks, not unspent-DBs
 191 2012-06-03 07:20:44 <bd_> of course, when bootstrapping, if you have a trusted node, you can inherit its current-state database and replay from there too
 192 2012-06-03 07:22:41 <bd_> anyway, all this follows from the security requirements of the protocol
 193 2012-06-03 07:22:54 <bd_> the representation of the unspent DB is a secondary concern
 194 2012-06-03 07:23:15 <amiller> i agree with everything you wrote
 195 2012-06-03 07:23:16 <bd_> (and a hash table might be a better choice than a binary tree, if you have a SSD :)
 196 2012-06-03 07:23:27 <amiller> i'm not sure what it is you objected to originally
 197 2012-06-03 07:23:37 <bd_> 03:05 < amiller> forrestv, i wonder if by 'flipping' you mean making the 'unspent coins database' the primary datastructure in the protocol, instead of the
 198 2012-06-03 07:23:39 <amiller> i think about which is the primary structure
 199 2012-06-03 07:23:40 <bd_>                  'blockchain' history?
 200 2012-06-03 07:23:44 <bd_> 03:14 < amiller> you _can_ trust another node to compute the transition in the unspend DB
 201 2012-06-03 07:23:59 <bd_> You can't trust another node to compute the transition
 202 2012-06-03 07:24:10 <bd_> as they may be a malicious node (ie, byzantine failure)
 203 2012-06-03 07:24:17 <bd_> you need to check their work
 204 2012-06-03 07:24:31 <amiller> let me rephrase that then, you _can_ double check the transition in the unspend DB
 205 2012-06-03 07:24:35 <amiller> even if you only have the current root hash
 206 2012-06-03 07:24:39 <amiller> that isn't possible with a hash table
 207 2012-06-03 07:25:03 <amiller> you'd have to have the whole hash table to verify the transition
 208 2012-06-03 07:25:24 <bd_> sure, but why do you need the root hash of the unspent db then?
 209 2012-06-03 07:25:32 <bd_> oh, I see what you're saying now
 210 2012-06-03 07:26:42 <bd_> essentially representing the state of the system with the root of a hash tree, then transmitting all mutated nodes with the state transition (ie, you send prior values of the nodes and the transition function in the block)
 211 2012-06-03 07:27:06 <bd_> and presumably only store the nodes of interest to you locally? (ie, nodes where you have coins)
 212 2012-06-03 07:27:38 <amiller> i don't think that a block needs to contain the prior values of the nodes, or anything other than it does currently
 213 2012-06-03 07:27:59 <amiller> but in order to verify the transactions in a block, a client would need some untrusted auxiliary data called a Verification Object
 214 2012-06-03 07:28:03 <bd_> if it has nothing more than it has now, you haven't changed the protocol :)
 215 2012-06-03 07:28:36 <bd_> so
 216 2012-06-03 07:28:45 <bd_> the root hash of the unspent db does need to be trusted
 217 2012-06-03 07:29:03 <amiller> partially.
 218 2012-06-03 07:29:08 <bd_> although it can be trusted because it's locally computed in the bootstrapping process
 219 2012-06-03 07:29:13 <amiller> it needs to be trusted in the sense that the byzantine fault tolerant network decides on its ordering
 220 2012-06-03 07:29:26 pierre` has quit (Ping timeout: 246 seconds)
 221 2012-06-03 07:29:27 <bd_> well, we already have transaction ordering
 222 2012-06-03 07:30:07 <bd_> anyway, what this boils down to is storing your _own_ unspent db in an untrusted third party, and just remembering the root hash so you can check that the untrusted third party hasn't done anything to it
 223 2012-06-03 07:30:14 <amiller> someone who has a full node now, would gain absolutely nothing from this
 224 2012-06-03 07:30:23 <amiller> the point is to make verification viable for people who only store O(1) root hashes of state
 225 2012-06-03 07:30:34 <amiller> i think that's compatible with what you just wrote
 226 2012-06-03 07:30:41 <bd_> as a further refinement, you can arrange to use the same procedure for storing your unspent db, and share storage with other users
 227 2012-06-03 07:30:47 <bd_> (mutually untrusted users, of course)
 228 2012-06-03 07:30:51 <bd_> seems sensible
 229 2012-06-03 07:31:22 <amiller> even better than that, i want to have an incentive system for the people who store these untrusted unspend dbs.
 230 2012-06-03 07:31:25 <bd_> you might also want to push tree nodes needed to verify a block along with the block itself, to speed block acceptance
 231 2012-06-03 07:32:10 <bd_> amiller: seems like it would be simple enough - just have a normal pay-to-get-a-login system?
 232 2012-06-03 07:32:17 RainbowDashh has joined
 233 2012-06-03 07:32:19 <bd_> I mean, any untrusted third-party will do
 234 2012-06-03 07:32:22 <bd_> heck, store it in S3
 235 2012-06-03 07:32:23 <amiller> the incentive system i'd like is to replace mining proof-of-work with one based on demonstrating random access to this unspend db.
 236 2012-06-03 07:33:00 <bd_> amiller: all nodes require random access to the unspent DB to verify transactions... that's not much of a proof of work
 237 2012-06-03 07:33:25 <bd_> I mean, the system is based on the assumption that random access to the unspent DB is much cheaper than the proof of work
 238 2012-06-03 07:33:41 <bd_> I don't think this needs to be bolted onto the core protocol
 239 2012-06-03 07:34:02 <bd_> just send some BTC to $third-party to get them to issue you a password (or enable access from your public key, etc)
 240 2012-06-03 07:34:03 <amiller> well the proof of work is a single hash right now
 241 2012-06-03 07:34:12 <amiller> but mining requires millions and millions of hashes
 242 2012-06-03 07:34:38 <bd_> sure
 243 2012-06-03 07:34:40 <amiller> likewise the proof-of-work would be a constant number of entries from the unspent-coins db, but the work itself would require tons of throughput
 244 2012-06-03 07:34:55 <bd_> but the thing about the POW is that you need to be able to _verify_ the proof-of-work in a _much_ shorter time than it was created
 245 2012-06-03 07:35:01 <amiller> right
 246 2012-06-03 07:35:10 <bd_> if you start creating a random-access-based POW, how do you verify that without doing the work again?
 247 2012-06-03 07:35:26 <amiller> i'll describe it, i also have a link to a paper by ron rivest that gave me the idea
 248 2012-06-03 07:35:39 <amiller> you start with a nonce, and you hash it and use that to select a random element from the database
 249 2012-06-03 07:36:08 <amiller> then you also hash that data when you look it up, and combine it with the previous hash. now you use that hash to select the next element
 250 2012-06-03 07:36:23 <amiller> you keep going for k times, at the end, you see if your hash has a lot of zeroes in the front, if so you announce your winning block
 251 2012-06-03 07:37:02 <bd_> hmm, okay. So you need fast access to the DB to compute this. But what's your incentive for providing it to others?
 252 2012-06-03 07:37:44 <amiller> http://people.csail.mit.edu/rivest/BowersVanDijkJuelsOpreaRivest-HowToTellIfYourCloudFilesAreVulnerableToDriveCrashes.pdf this is the paper i mentioned by the way that includes the above description, basically.
 253 2012-06-03 07:39:05 username57913 has quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
 254 2012-06-03 07:39:10 <amiller> it doesn't provide an incentive to share it, just an incentive to have it.
 255 2012-06-03 07:39:20 <amiller> i think that's sufficient and optimal but i'm not too sure of this part.
 256 2012-06-03 07:39:31 <amiller> the way i think of it is that right now, mining requires an unspent coin database and also a gpu
 257 2012-06-03 07:39:38 <amiller> you get reimbursed in some sense by adding more gpus
 258 2012-06-03 07:39:48 <bd_> mining nodes don't really need the unspent db
 259 2012-06-03 07:39:53 <bd_> they just need a control node that has said db
 260 2012-06-03 07:39:59 <bd_> heck, not even that
 261 2012-06-03 07:40:03 <bd_> you just need the previous block
 262 2012-06-03 07:40:10 <bd_> and you can issue new blocks that only have a coin-minting txn :D
 263 2012-06-03 07:40:23 <amiller> right
 264 2012-06-03 07:40:25 <bd_> I mean, currently, that is.
 265 2012-06-03 07:40:26 <amiller> and in fact, it's cheaper that way
 266 2012-06-03 07:40:27 <bd_> anyway
 267 2012-06-03 07:40:35 <amiller> if the mining and the double checking were unified
 268 2012-06-03 07:40:37 <bd_> the thing you want to incentivize is not keeping the unspent db around
 269 2012-06-03 07:40:42 <bd_> it's making it available to _others_
 270 2012-06-03 07:40:48 <bd_> the whole point is not everyone needs to maintain this db
 271 2012-06-03 07:40:56 <amiller> everyone needs access to it though
 272 2012-06-03 07:41:08 <bd_> so you don't want to create an incentive for everyone to maintain their own db in RAM because otherwise they can't mine
 273 2012-06-03 07:41:26 <bd_> you want to create an incentive for a number of providers to provide access to their DBs
 274 2012-06-03 07:41:44 <bd_> which is not what your hashing thing would do. Indeed, you'd want to monopolize access to your DB so others don't use it for their own mining
 275 2012-06-03 07:41:53 <bd_> The solution is really very simple
 276 2012-06-03 07:41:57 <bd_> just pay for access to a db provider
 277 2012-06-03 07:42:17 <bd_> no need for fancy cryptography, just an ordinary contract
 278 2012-06-03 07:42:39 <bd_> pay with micropayments so a scam provider doesn't get very much money, if you want to be fancy about it
 279 2012-06-03 07:43:20 <amiller> the point of the technique in that rivest paper is to have a way of checking is a service provider is really doing the job they say they are
 280 2012-06-03 07:43:21 <bd_> hmm
 281 2012-06-03 07:43:24 <bd_> I find some of the flawed assumptions in that rivest paper quite interesting ;)
 282 2012-06-03 07:43:49 <amiller> er, yeah if you're talking about the assumptions about hard drive performance characteristics then yeah
 283 2012-06-03 07:43:56 <bd_> there are ways to get really good redundancy without improvements in seek times
 284 2012-06-03 07:44:05 <bd_> can't say more about that though
 285 2012-06-03 07:44:26 username57913 has joined
 286 2012-06-03 07:44:45 <amiller> you can purchase a subscription to a db provider and make them perform proofs-of-work for you
 287 2012-06-03 07:46:03 <amiller> i think i'm still missing some kind of explanation here about why it works out that it's so useful to align the proof-of-work with the validation task.
 288 2012-06-03 07:46:25 <amiller> mining has the effect of subsidizing investment in gpus and other mining hardware
 289 2012-06-03 07:46:35 <bd_> well, no, I think you're asking people to prove the wrong thing
 290 2012-06-03 07:46:36 <amiller> the work itself necessarily has to be burnt cycles
 291 2012-06-03 07:46:40 <bd_> it's all about incentives
 292 2012-06-03 07:46:48 <amiller> but the subsidized investment doesn't need to be wasted
 293 2012-06-03 07:46:55 <bd_> what do we want to encourage people to do?
 294 2012-06-03 07:47:12 <bd_> subsidize DRAM manufacturers? :)
 295 2012-06-03 07:47:14 <amiller> you want to reduce the costs needed to participate in the network, to encourage decentralization
 296 2012-06-03 07:47:25 Joric_ is now known as Joric
 297 2012-06-03 07:47:35 <amiller> it's not about the storage hardware in this case, it's about what the storage hardware is _storing_
 298 2012-06-03 07:47:47 <bd_> sure. but making the POW demonstrate possession of the unspent DB doesn't achieve that goal
 299 2012-06-03 07:48:01 <bd_> you proved that you have the db, you haven't proved that you're making it available to others
 300 2012-06-03 07:48:14 <amiller> but if you make it available to others, you can prove that to them
 301 2012-06-03 07:48:14 <bd_> and like I said, there's a disincentive to making this db available
 302 2012-06-03 07:49:02 <bd_> amiller: They need access to the db anyway, to participate in bitcoin at all. If I were mining, why would _I_ personally want to sacrifice memory bandwidth to making my db available?
 303 2012-06-03 07:49:27 <bd_> A rational miner would just put it onto a dedicated box and have it only serve queries from the mining program.
 304 2012-06-03 07:49:47 <bd_> They might _also_ operate a public db, potentially for a fee, but this is orthogonal to the proof-of-work
 305 2012-06-03 07:49:47 <amiller> think of the miner as separate from the db provider
 306 2012-06-03 07:49:52 <bd_> indeed
 307 2012-06-03 07:49:54 <amiller> providing the db is an untrusted service
 308 2012-06-03 07:50:09 <amiller> miners then are nodes that hire the untrusted db provider
 309 2012-06-03 07:50:11 <bd_> sure. my point is making the POW be DB access does not impact whether there are db providers
 310 2012-06-03 07:50:21 <bd_> no, that won't be the case
 311 2012-06-03 07:50:28 <bd_> if your POW is based on latency to the DB
 312 2012-06-03 07:50:30 <amiller> you mine when you pay an untrusted db provider to send you back a proof of work that includes a block winning bonus to yourself
 313 2012-06-03 07:50:33 <bd_> you can't use an external DB
 314 2012-06-03 07:50:56 <bd_> amiller: why wouldn't the db provider just find a proof-of-work that pays themselves then?
 315 2012-06-03 07:51:28 <bd_> the db provider has no reason to implement proof-of-work computation only to pay part of it to a middleman
 316 2012-06-03 07:51:38 <bd_> they can do the tiny amount of additional work to prepare the block themselves
 317 2012-06-03 07:52:00 <bd_> hence why I say it'd be subsidizing DRAM manufacturers - here the best strategy is to store the entire database in memory, so lookups are extremely fast
 318 2012-06-03 07:52:46 <amiller> we're not being very precise about what the different roles are here, especially between verifiers, unspent db providers, and miners
 319 2012-06-03 07:52:57 <amiller> but the point is to subsidize the thing that's expensive and helps verifiers
 320 2012-06-03 07:53:08 <bd_> and my point is that this incentive does not have that effect
 321 2012-06-03 07:53:08 copumpkin has quit (Ping timeout: 245 seconds)
 322 2012-06-03 07:53:15 <bd_> miners have no incentive to make their db available to others
 323 2012-06-03 07:53:27 <amiller> miners have an incentive to hire unspent db providers
 324 2012-06-03 07:53:30 <bd_> db providers have no incentive to assist in mining
 325 2012-06-03 07:53:32 <amiller> unspent db providers can sell subscriptions to verifiers
 326 2012-06-03 07:53:40 copumpkin has joined
 327 2012-06-03 07:53:46 <bd_> but db providers can indeed sell subscriptions to verifiers
 328 2012-06-03 07:53:58 <amiller> right and those subscriptions are cheaper if they're subsidized by mining as well
 329 2012-06-03 07:54:25 <bd_> why would they be subsidized? like I said, the db provider has no reason to let the miners have a cut of any proof-of-work computation said provider may or may not do
 330 2012-06-03 07:54:37 <bd_> If the DB provider does the POW computation, that makes the DB provider a miner.
 331 2012-06-03 07:54:41 <amiller> that's fine
 332 2012-06-03 07:54:45 <amiller> that's not the part that needs subsidizing
 333 2012-06-03 07:54:53 <bd_> Which is indeed fine, but my point is miners need to have a copy of the DB locally
 334 2012-06-03 07:55:03 <bd_> so they have no reason to subsidize db providers
 335 2012-06-03 07:55:04 <amiller> not if they hire unspent db providers
 336 2012-06-03 07:55:18 <amiller> if the have the copy of the db locally then they've also invested in an unspend db
 337 2012-06-03 07:55:20 <amiller> and they can sell a subscription
 338 2012-06-03 07:55:35 <bd_> amiller: the network latency involved in connecting to a db provider makes it impractical to mine-at-a-distance. A local copy will produce much better results
 339 2012-06-03 07:55:43 <amiller> you don't need to do round trips
 340 2012-06-03 07:55:55 <bd_> and offloading the entire POW computation to the db is not something that a rational db provider would allow
 341 2012-06-03 07:56:00 <amiller> you just tell the db provider to mine for you and you pay them for the best proof of work they can provide
 342 2012-06-03 07:56:16 <bd_> because if they're going to do that computation, they should take the entire reward for themselves
 343 2012-06-03 07:56:58 <bd_> and if you're paying for non-winning blocks
 344 2012-06-03 07:57:06 <bd_> then you've just reinvented the mining pool :)
 345 2012-06-03 07:57:23 <bd_> my point though is that having a db does not imply you want to provide public access
 346 2012-06-03 07:57:48 <bd_> for a miner, memory bandwidth is precious. To give some of it up to provide public access would require a suitable payment to offset the loss in mining efficiency
 347 2012-06-03 07:57:53 <amiller> my goal is to lower the marginal cost, if you're mining, of also providing public db access
 348 2012-06-03 07:57:55 <bd_> and many miners might not bother doing so
 349 2012-06-03 07:58:03 dvide has joined
 350 2012-06-03 07:59:06 <bd_> amiller: the other thing is, a DB meant for mining might not necessarily scale.
 351 2012-06-03 07:59:06 slush has quit (Read error: Connection reset by peer)
 352 2012-06-03 07:59:26 <bd_> consider one possible design for a public unspent DB: Shove all the blocks into S3 and have a server gating access to it
 353 2012-06-03 07:59:31 <bd_> Easy.
 354 2012-06-03 07:59:40 <bd_> Doesn't require the whole thing be in memory
 355 2012-06-03 07:59:51 <bd_> And, vitally, easily gives access to historical blocks
 356 2012-06-03 07:59:59 <bd_> The miner, on the other hand, only needs the _current_ blocks
 357 2012-06-03 08:00:00 <bd_> er
 358 2012-06-03 08:00:02 <bd_> current DB
 359 2012-06-03 08:00:17 <bd_> they can immediately discard the old DB when a new block comes along
 360 2012-06-03 08:00:24 <bd_> which is exactly when the old DB is needed by verifiers
 361 2012-06-03 08:00:43 <bd_> A rational miner will discard the data needed by verifiers exactly when the verifiers need it
 362 2012-06-03 08:00:57 <bd_> as they want to make room for the current DB to start mining from it immediately
 363 2012-06-03 08:01:41 <amiller> the old DB and the current DB mostly overlap
 364 2012-06-03 08:01:55 <bd_> mostly. but why bother storing the old one?
 365 2012-06-03 08:02:13 <amiller> if you want to make old ones covered by the incentive plan
 366 2012-06-03 08:02:16 <bd_> much easier to mutate it in-place
 367 2012-06-03 08:02:39 <amiller> it's easy to include that as well, when you select random entries you either select them from the current db, or select them from any of the previous dbs
 368 2012-06-03 08:02:53 <amiller> you could also have a sliding window that goes back to some finite amount of time
 369 2012-06-03 08:03:09 <amiller> this is described in one paper as a Persistent Authenticated Datastructure and it has one figure that's really cool and simple
 370 2012-06-03 08:03:24 slush has joined
 371 2012-06-03 08:03:32 <bd_> I suppose. It still doesn't incent people to make it accessible, though.
 372 2012-06-03 08:03:53 <amiller> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.9438
 373 2012-06-03 08:03:56 <bd_> the CPU and memory bandwidth cost of providing access would have to be more lucrative than mining
 374 2012-06-03 08:04:20 knotwork_ is now known as knotwork
 375 2012-06-03 08:05:25 <amiller> you can lead a horse to water but you can't make it drink
 376 2012-06-03 08:05:31 <bd_> perhaps :)
 377 2012-06-03 08:05:52 <bd_> anyway, I don't know if it's necessary
 378 2012-06-03 08:06:06 <bd_> If you were to introduce this, initially we have the current world, where everyone has their own unspent db
 379 2012-06-03 08:06:14 <bd_> for people to discard these dbs, unspent db providers must appear first
 380 2012-06-03 08:06:27 <bd_> these could be, e.g., pool master servers
 381 2012-06-03 08:06:36 <bd_> or just a random node somewhere
 382 2012-06-03 08:07:01 <bd_> there's no point in incentivizing people to have a full db when they _already do_
 383 2012-06-03 08:07:06 <amiller> i didn't mean to get so distracted talking about the proof of work part
 384 2012-06-03 08:07:10 <bd_> :)
 385 2012-06-03 08:07:11 <amiller> it's not nearly as important
 386 2012-06-03 08:07:15 <bd_> indeed
 387 2012-06-03 08:07:26 <bd_> I do think having a way to offload the unspent db is a nice idea though
 388 2012-06-03 08:07:55 <amiller> yeah what i am hoping to do is start solving that part, which doesn't even require any network changes
 389 2012-06-03 08:08:17 <bd_> as I said before, it would be very helpful, though, to push any nodes needed to verify a block along with said block
 390 2012-06-03 08:08:30 <bd_> otherwise you'll have a thundering herd scenario whenever a block is found
 391 2012-06-03 08:08:57 <amiller> but you just look it up in your database
 392 2012-06-03 08:09:15 <bd_> the verifiers don't have their db, right?
 393 2012-06-03 08:09:31 <amiller> not if they have access to an untrusted db provider
 394 2012-06-03 08:09:31 <bd_> when a new block is published, all verifiers need to fetch whatever tree nodes are needed to verify said block
 395 2012-06-03 08:09:34 <bd_> at approximately the same time
 396 2012-06-03 08:09:41 <bd_> thus overwhelming the untrusted db providers
 397 2012-06-03 08:10:04 <amiller> the verifiers CAN have their own db, and they probably will continue to just as they do now
 398 2012-06-03 08:10:13 <amiller> the point is that it's not requred because you CAN offload it if you choose to as well
 399 2012-06-03 08:10:20 <bd_> offloaded clients, then
 400 2012-06-03 08:10:27 <bd_> which also participate as verifiers
 401 2012-06-03 08:10:34 <amiller> SPVs require helpers
 402 2012-06-03 08:10:41 <amiller> that's still true
 403 2012-06-03 08:10:42 <bd_> point is, when a block comes out, all offloaded clients start fetching the same data at once
 404 2012-06-03 08:11:01 <bd_> far better to gossip the blocks around to avoid this kind of load spike
 405 2012-06-03 08:11:07 <bd_> er, gossip the tree nodes around rather
 406 2012-06-03 08:13:27 Edward_Black has quit (Ping timeout: 272 seconds)
 407 2012-06-03 08:14:09 <amiller> i don't see why they need to be included in the block vs not included in the block
 408 2012-06-03 08:14:21 <bd_> it's not necessary for the protocol, and I'
 409 2012-06-03 08:14:27 <bd_> m not suggesting they be _part_ of the block
 410 2012-06-03 08:14:41 <bd_> just gossiped around with the block, to reduce the impact of load spikes on these DB providers
 411 2012-06-03 08:14:47 <amiller> okay, then i agree totally with that
 412 2012-06-03 08:15:05 <bd_> you could argue that peers have no incentive to gossip the nodes
 413 2012-06-03 08:15:14 <bd_> but they don't really have an incentive to gossip the blocks either
 414 2012-06-03 08:15:23 <amiller> i would _not_ have made that argument :p
 415 2012-06-03 08:15:28 <bd_> :)
 416 2012-06-03 08:15:43 <amiller> so you mentioned that bitcoin is a byzantine consensus protocol
 417 2012-06-03 08:15:55 <amiller> i've been hoping to talk to someone about that a bit
 418 2012-06-03 08:16:12 <amiller> all the byzantine consensus protocols include 'message delays', that turns out to be like half the challenge of the problem
 419 2012-06-03 08:16:20 <bd_> It would be so much simpler if it didn't need to be resilient to byzantine failures :)
 420 2012-06-03 08:16:27 <bd_> well, that's not even a byzantine failure
 421 2012-06-03 08:16:33 <bd_> eg even paxos has to deal with message delays
 422 2012-06-03 08:16:40 <amiller> the challenges are 1) just shy of half the nodes might be faulty,  and 2) the messages between nodes, even the non-faulty ones, can be delayed by arbitrary amounts
 423 2012-06-03 08:17:24 <bd_> which basically means it might take a very long time to converge in the presence of message delays
 424 2012-06-03 08:17:42 <bd_> all nodes thus have a very strong incentive to _receive_ messages from other nodes quickly
 425 2012-06-03 08:17:54 <amiller> regarding different kinds of message delays, a) in the synchronous case, messages are delayed by up to some maximum bound, but that bound is known ahead of time (e.g. paxos)  b) in the partially synchronous case, the message delay bound exists but is not known  and c) if there is no message bound, it's 'asynchronous' and its' impossible
 426 2012-06-03 08:17:55 <bd_> they don't necessarily have an incentive to ensure that other nodes receive messages from other nodes quickly
 427 2012-06-03 08:18:00 <amiller> so only a) and b) are worth looking at
 428 2012-06-03 08:18:24 <amiller> the proof in the bitcoin whitepaper is about some non-existent-in-academia setting in which implicitly there are no message delays
 429 2012-06-03 08:18:47 <bd_> message delays basically can result in blockchain forks
 430 2012-06-03 08:19:05 <amiller> the forks are guaranteed to go away after some time
 431 2012-06-03 08:19:15 <bd_> that time is the bound on propagation delay :)
 432 2012-06-03 08:19:38 <amiller> forks can also be caused by the byzantine failures
 433 2012-06-03 08:20:05 <bd_> In the nearly-half-are-malicious case, if all messages from the 'healthy' nodes are delayed beyond the point where nodes commit to the current block chain
 434 2012-06-03 08:20:09 <amiller> and the byzantine adversary is given the advantage of zero message delays
 435 2012-06-03 08:20:26 <bd_> then the malicious block chain could be accepted by a majority of nodes, despite better POWs potentially existing in the healthy nodes
 436 2012-06-03 08:20:43 <amiller> so the byzantine consensus protocols have a couple of important qualities
 437 2012-06-03 08:21:00 <amiller> one is that the nodes in a consensus protocol eventually 'decide'
 438 2012-06-03 08:21:04 <bd_> the gossip protocol helps prevent this though, as it's very difficult to construct a scenario where all healthy node gossip is blocked but malicious<->healthy node gossip isn't
 439 2012-06-03 08:21:24 <amiller> deciding is a one-time-only irreversible action, and the definition of the game is that there should never be a fork decision
 440 2012-06-03 08:21:31 <amiller> the closest analogue to this in bitcoin-world is the 6 blocks rule
 441 2012-06-03 08:22:03 <amiller> we might say that nodes 'decide' after 6 blocks, and we'd want the claim to be that any forks after 6 blocks can only occur with negligible probability
 442 2012-06-03 08:22:45 <amiller> if negligible probability is defined as exponentially small for some security parameter k, then then the number of blocks required should hopefully be polynomial in k
 443 2012-06-03 08:23:45 <amiller> the point of this puzzle is you have a fight between a 51% with message delays, and a 49% with no message delays
 444 2012-06-03 08:24:15 <amiller> can you prove that the stronger 51% cpu will win out after some amount of time, despite the message delay
 445 2012-06-03 08:24:27 <bd_> only if you put an upper bound on the delays
 446 2012-06-03 08:25:05 <bd_> otherwise, you could construct a scenario in which delays are so high that every node in the 51% believes the only nodes that exist are itself and the 49% of evil nodes
 447 2012-06-03 08:25:45 <amiller> right
 448 2012-06-03 08:26:08 <amiller> so then there are two cases a) the upper bound is known, call it M, and b) it exists but it's not known
 449 2012-06-03 08:26:24 <bd_> unknown isn't good enough
 450 2012-06-03 08:26:35 <bd_> any healthy node N can make a guess at the upper bound B
 451 2012-06-03 08:26:41 <amiller> i'm following along with this paper btw http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf
 452 2012-06-03 08:26:45 <bd_> when B time elapses, N must decide whether it believes that a decision has been made
 453 2012-06-03 08:27:12 <bd_> if it hasn't heard from ANY healthy nodes yet (because its guess for B was too small), it will believe that the unhealthy nodes have made whatever decision they claim to have made
 454 2012-06-03 08:27:17 <amiller> bd_, how about if we assume that we know the total strength of the network ahead of time?
 455 2012-06-03 08:27:38 <amiller> in most byzantine consensus protocols, the number N of nodes is a known parameter, of course the nodes are all known ahead of time, there are very few 'anonymous' node papers
 456 2012-06-03 08:28:22 <bd_> I guess you could assume the entire network is unhealthy if you see less than 51% of the strength you expect before B
 457 2012-06-03 08:28:59 <bd_> of course, what happens if the malicious nodes allow a few virtual networks to form - say, each one consists of all malicious nodes, and 50% of the healthy nodes
 458 2012-06-03 08:29:13 <bd_> so each healthy node sees 74% of the network and declares itself in a healthy network
 459 2012-06-03 08:29:17 <bd_> but actually there are two split networks
 460 2012-06-03 08:29:22 <bd_> which come to different decisions
 461 2012-06-03 08:29:31 <bd_> controlled by the unhealthy nodes
 462 2012-06-03 08:30:01 <amiller> there's no way to observe more than 100% of the network in total
 463 2012-06-03 08:30:11 <amiller> the 50% has to split its effort
 464 2012-06-03 08:30:17 <amiller> er 49%*
 465 2012-06-03 08:30:46 slush has quit (Read error: Connection reset by peer)
 466 2012-06-03 08:30:52 <bd_> hmm, I see
 467 2012-06-03 08:30:56 <bd_> I suppose that would work
 468 2012-06-03 08:30:58 <amiller> in byzantine protocol papers the network is N = 2f+1,   the bad guys are f,  the good guys are f+1
 469 2012-06-03 08:31:07 <amiller> we have 100%, 49%, and 51% respectively!
 470 2012-06-03 08:31:08 <bd_> but it's not relevant for bitcoin, as the strength of the network is also an unknown
 471 2012-06-03 08:31:25 <amiller> deciding also isn't part of bitcoin either
 472 2012-06-03 08:31:48 <amiller> so i think it's fair to address the theoretical distributed systems part of bitcoin this way
 473 2012-06-03 08:31:58 slush has joined
 474 2012-06-03 08:32:08 <bd_> deciding is part of bitcoin
 475 2012-06-03 08:32:09 <amiller> by saying that we can construct a protocol that decides as long as we know the strength of the network
 476 2012-06-03 08:32:17 <bd_> the decision is simple - which transaction spent coin C?
 477 2012-06-03 08:32:22 <bd_> there may be multiple candidates
 478 2012-06-03 08:32:35 <amiller> i mean making a final irreversible decision
 479 2012-06-03 08:32:41 <amiller> we're more concerned with the idea that it will converge
 480 2012-06-03 08:32:48 <amiller> rather than that it will actually end
 481 2012-06-03 08:32:48 <bd_> effectively, it does at some point
 482 2012-06-03 08:33:09 <bd_> eg, after 6 blocks pass
 483 2012-06-03 08:33:22 <amiller> if you know the size of the network, then you can decide irreversibly.
 484 2012-06-03 08:33:29 <bd_> yes, but that's a very big if
 485 2012-06-03 08:33:34 <amiller> well see the 6 blocks passing aspect of bitcoin implies some kind of network measurement
 486 2012-06-03 08:33:36 <bd_> byzantine hosts may try to confound your estimates
 487 2012-06-03 08:33:45 <bd_> eg, those 49% might only spend 1% of their effort for a while
 488 2012-06-03 08:33:55 <bd_> and act as healthy nodes with that level of effort
 489 2012-06-03 08:34:06 <bd_> when they split the network, they then expend all of their effort
 490 2012-06-03 08:34:19 <amiller> sure, they might work invisibly
 491 2012-06-03 08:34:40 <amiller> i mean i agree with you i think, that's another difficult point to resolve
 492 2012-06-03 08:34:47 <amiller> i'm really just talking about a first step
 493 2012-06-03 08:34:48 <bd_> I think it's a fundamental point, actually
 494 2012-06-03 08:35:06 <bd_> it's one that bitcoin actually tries to estimate already, in fact
 495 2012-06-03 08:35:25 <bd_> (in order to set the right level of POW)
 496 2012-06-03 08:36:45 <amiller> i'll be happy if i can show that knowing the strength of the network is sufficient to do byzantine consensus in the a) synchronous and b) partial synchronous message delay scenarios
 497 2012-06-03 08:36:52 <bd_> fair enough :)
 498 2012-06-03 08:37:22 <amiller> but if it's possible to do it with even less than that, like if you don't know the strength of the network, that would be even better
 499 2012-06-03 08:37:23 <amiller> hm
 500 2012-06-03 08:37:41 <amiller> one thing i tried was if you only know the strength of the adversary but not the full size of the network
 501 2012-06-03 08:37:55 <amiller> (if you know f but not N, in distributed systems)
 502 2012-06-03 08:37:56 <bd_> well, then you know the size of the network
 503 2012-06-03 08:38:07 <bd_> you can assume N >= 2f+epsilon
 504 2012-06-03 08:38:19 <amiller> right but if you don't know N
 505 2012-06-03 08:38:22 <bd_> otherwise the evil nodes control more than half of the network and you're doomed nayway
 506 2012-06-03 08:38:25 <amiller> and you make a decision just based on f
 507 2012-06-03 08:38:33 <amiller> then you're vulnerable to partitions
 508 2012-06-03 08:38:59 <bd_> why's that?
 509 2012-06-03 08:38:59 slush has quit (Read error: Connection reset by peer)
 510 2012-06-03 08:39:02 <amiller> knowing f but not N means your protocol can't distinguish between N=3f+1 and N=2f+!
 511 2012-06-03 08:39:13 <amiller> or N=100f+1
 512 2012-06-03 08:39:53 <amiller> but if you have a protocol that can come to a decision based on only knowing f, and it works in the 2f+1 case, then you could have dozens of those networks in the 100f+1 case, and they could all come to different decisions
 513 2012-06-03 08:40:11 <amiller> maybe not if the message bound is known
 514 2012-06-03 08:40:13 <bd_> oh, I see.
 515 2012-06-03 08:40:32 <amiller> i think if you know the message bound then you don't need to know the size of the network
 516 2012-06-03 08:40:38 <amiller> i must have only been worried about this for the partial synchrony case
 517 2012-06-03 08:41:10 <bd_> ah, I see, the byzantine nodes could partition the network into multiple networks, each independently healthy but coming to different decisions, got you.
 518 2012-06-03 08:41:32 <bd_> but yea, if you know the message bound, you just wait until that amount of time passes, and you know you've heard from all healthy nodes
 519 2012-06-03 08:42:17 <bd_> so the network cannot be split
 520 2012-06-03 08:43:40 _Fireball has joined
 521 2012-06-03 08:44:27 <amiller> perhaps then the 6 blocks / 10 minutes then can be interpreted just as well as _either_ an assumption about message delays _or_ an assumption about the size of the network
 522 2012-06-03 08:44:59 <bd_> message delays, really
 523 2012-06-03 08:45:11 <bd_> with unbounded message delays, the byzantine partition will eventually reach 6 blocks
 524 2012-06-03 08:45:20 <bd_> it just will take a little over twice as long as usual
 525 2012-06-03 08:46:10 <bd_> actually, perhaps it's an assumption about both
 526 2012-06-03 08:46:45 <bd_> you're assuming the total strength of the network is such that the byzantine nodes can't construct a 6-block chain in any amount of time shorter than the message delay bound
 527 2012-06-03 08:46:50 <bd_> or something.
 528 2012-06-03 08:47:40 <bd_> if your assumption about the message delay bound is wrong, you might be in a partition with the byzantine nodes, and they might be able to produce those 6 blocks before you can talk to another healthy node
 529 2012-06-03 08:47:58 <amiller> i had to make a new thing to deal with this problem, when you don't know the message bound
 530 2012-06-03 08:48:10 <bd_> if your assumption about network strength is wrong, the byzantine nodes again might be able to churn through 6 blocks really quickly
 531 2012-06-03 08:48:14 <amiller> what i came up with is that you don't pick a particular difficulty threshold, i.e. 15 zeroes in front of your hashes
 532 2012-06-03 08:48:32 <amiller> instead you sort of play the game for all numbers of zeroes
 533 2012-06-03 08:48:42 <amiller> (if you get a perfect hash collision i guess you roll twice and so on)
 534 2012-06-03 08:48:57 <amiller> no matter what the message delay bound is, eventually there is some event that happens infrequently enough
 535 2012-06-03 08:49:14 <amiller> that the delayed 51% will pull ahead of the byzantine zero delay 49%
 536 2012-06-03 08:49:29 <amiller> instead of making a decision based on a constant number of blocks,
 537 2012-06-03 08:49:47 <bd_> not really
 538 2012-06-03 08:49:56 <amiller> you make your decision based on the amount of time that's elapsed and the strength of the network
 539 2012-06-03 08:50:15 <bd_> er, well, yes, you're making an assumption based on network strength again
 540 2012-06-03 08:50:25 <amiller> but not on knowing the message bound
 541 2012-06-03 08:50:51 <bd_> sure. this is like saying, "I'll accept this if I see it confirmed with 6 blocks in under 12 hours."
 542 2012-06-03 08:50:59 Nicksasa has quit (Ping timeout: 246 seconds)
 543 2012-06-03 08:51:20 <bd_> And if it takes more than 12 hours you assume there is a massive conspiracy and swear off bitcoin forever
 544 2012-06-03 08:51:41 <bd_> (or increase the number of blocks you want to see)
 545 2012-06-03 08:51:50 <amiller> right
 546 2012-06-03 08:52:15 <bd_> problem is, difficulty estimates in bitcoin aren't fixed, so once you go beyond the point of a difficulty recalc you're screwed :)
 547 2012-06-03 08:52:35 <amiller> well so that's how it can work if you know the network strength but not the message delay bound
 548 2012-06-03 08:52:41 <bd_> indeed.
 549 2012-06-03 08:53:25 <amiller> and if you know the message delay bound but not the network strength.... i forget what happened in that case
 550 2012-06-03 08:53:53 <amiller> maybe that's where you know the size of the adversary but maybe not the total size of the network (you know f but not N)
 551 2012-06-03 08:54:06 <bd_> it's not that hard if you know the message delay bound
 552 2012-06-03 08:54:17 <bd_> and membership is fixed
 553 2012-06-03 08:54:27 <bd_> first, give each node a cryptographic identity
 554 2012-06-03 08:54:40 <bd_> now, in each round, all nodes vote on the decision, and send their votes to all other nodes
 555 2012-06-03 08:54:50 <bd_> signed with their crypto identity
 556 2012-06-03 08:55:05 <bd_> then they wait $messageDelayBound
 557 2012-06-03 08:55:12 <bd_> and go with whatever got the most votes
 558 2012-06-03 08:55:27 <bd_> assuming all healthy nodes vote the same way, this should work
 559 2012-06-03 08:56:05 <bd_> ie, they have some kind of deterministic protocol to choose the winner... wait
 560 2012-06-03 08:56:08 <bd_> nevermind ><
 561 2012-06-03 08:56:39 <bd_> this is what I get for thinking up protocols on the fly at 1:53 am
 562 2012-06-03 08:57:48 <amiller> well, i follow where you were going with that - it's easy if membership is fixed and message delay bound is known
 563 2012-06-03 08:58:04 <bd_> fixed per-round
 564 2012-06-03 08:58:08 <bd_> you can always vote in new members
 565 2012-06-03 08:58:20 <bd_> it just needs to be part of the protocol
 566 2012-06-03 08:58:29 <amiller> i can't figure out if it's worthwhile to look at where you know just the size of the adversary but not the total size of membership
 567 2012-06-03 08:58:56 <amiller> like if f is part of the protocol but not N
 568 2012-06-03 08:59:15 <bd_> how would f be part of the protocol?
 569 2012-06-03 08:59:29 <bd_> I mean, realistically. Just an assumed upper bound?
 570 2012-06-03 09:00:19 <amiller> well to be realistic i need to connect it back to the more fuzzy case with bitcoin in practice
 571 2012-06-03 09:00:22 <amiller> the 6 blocks rule is negotiable
 572 2012-06-03 09:00:35 <amiller> you're supposed to consider the cost of what you're doing
 573 2012-06-03 09:01:13 <amiller> so i might say i know that it would cost more than $1000 to wind the network back more than 20 minutes
 574 2012-06-03 09:02:27 <bd_> ah, indeed
 575 2012-06-03 09:02:38 <amiller> that's analogous to an assessing f.
 576 2012-06-03 09:05:45 ThomasV has quit (Ping timeout: 245 seconds)
 577 2012-06-03 09:12:17 graingert has joined
 578 2012-06-03 09:13:54 slush has joined
 579 2012-06-03 09:15:59 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Remote host closed the connection)
 580 2012-06-03 09:16:20 superjames has quit (Ping timeout: 260 seconds)
 581 2012-06-03 09:16:32 darkee has joined
 582 2012-06-03 09:18:28 RazielZ has joined
 583 2012-06-03 09:20:03 Turingi has joined
 584 2012-06-03 09:22:13 TD has joined
 585 2012-06-03 09:28:57 superjames has joined
 586 2012-06-03 09:31:10 Skaag has quit (Read error: Connection reset by peer)
 587 2012-06-03 09:31:33 Skaag has joined
 588 2012-06-03 09:46:19 word has quit (Ping timeout: 276 seconds)
 589 2012-06-03 09:54:17 erle- has joined
 590 2012-06-03 09:55:12 Nicksasa has joined
 591 2012-06-03 09:55:12 Nicksasa has quit (Changing host)
 592 2012-06-03 09:55:12 Nicksasa has joined
 593 2012-06-03 09:55:31 slush has quit (Ping timeout: 252 seconds)
 594 2012-06-03 09:56:51 Edward_Black has joined
 595 2012-06-03 10:03:23 mmoya has joined
 596 2012-06-03 10:03:45 dinox has joined
 597 2012-06-03 10:05:57 graingert has quit (Read error: Connection reset by peer)
 598 2012-06-03 10:06:06 graingert has joined
 599 2012-06-03 10:18:41 datagutt has joined
 600 2012-06-03 10:47:14 <TD> good afternoon
 601 2012-06-03 10:51:29 word_ has joined
 602 2012-06-03 10:58:05 <molecular> hello
 603 2012-06-03 10:59:56 hnz has joined
 604 2012-06-03 11:03:12 word_ has quit (Changing host)
 605 2012-06-03 11:03:12 word_ has joined
 606 2012-06-03 11:03:20 word_ is now known as word
 607 2012-06-03 11:09:13 <gribble> New news from bitcoinrss: Diapolo opened pull request 1412 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1412>
 608 2012-06-03 11:16:20 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
 609 2012-06-03 11:22:04 tower has joined
 610 2012-06-03 11:22:20 ovidiusoft has quit (Ping timeout: 260 seconds)
 611 2012-06-03 11:34:05 rdponticelli has quit (Ping timeout: 245 seconds)
 612 2012-06-03 11:34:45 grondilu has joined
 613 2012-06-03 11:37:11 darkee is now known as !~darkee@gateway/tor-sasl/darkee|darkee
 614 2012-06-03 11:38:34 <grondilu> Has anyone ported Genjix's bitcoin.sql to MySQL?
 615 2012-06-03 11:41:44 JZavala has quit (Ping timeout: 240 seconds)
 616 2012-06-03 11:43:30 skeledrew has joined
 617 2012-06-03 11:44:40 grondilu has quit (Quit: leaving)
 618 2012-06-03 11:50:39 <gribble> New news from bitcoinrss: Diapolo opened pull request 1413 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1413>
 619 2012-06-03 11:56:44 t7 has joined
 620 2012-06-03 12:10:08 talpan has joined
 621 2012-06-03 12:14:14 slush has joined
 622 2012-06-03 12:17:08 Tuxavant has joined
 623 2012-06-03 12:19:22 <Tuxavant> Looking to hire a tutor to walk me thru building OpenSSL with EC, write a spec file, and get it into a personal or generic 3rd party repository. fedora centric. Just need someone to guide me and bounce questions off when I fail. $20 USD in Bitcoins for your trouble. Assistance via PM and mail.
 624 2012-06-03 12:22:03 phma has joined
 625 2012-06-03 12:24:36 theorbtwo has quit (Read error: Connection reset by peer)
 626 2012-06-03 12:28:35 theorbtwo has joined
 627 2012-06-03 12:29:22 slush has quit (Read error: Connection reset by peer)
 628 2012-06-03 12:32:17 apex-alt has joined
 629 2012-06-03 12:32:47 Apexseals has quit (Ping timeout: 260 seconds)
 630 2012-06-03 12:33:08 leviTate has joined
 631 2012-06-03 12:33:14 copumpkin has quit (Ping timeout: 240 seconds)
 632 2012-06-03 12:33:16 slush has joined
 633 2012-06-03 12:34:11 banshee12 has quit (Ping timeout: 260 seconds)
 634 2012-06-03 12:36:43 copumpkin has joined
 635 2012-06-03 12:36:50 copumpkin has quit (Changing host)
 636 2012-06-03 12:36:50 copumpkin has joined
 637 2012-06-03 12:39:39 one_zero has quit ()
 638 2012-06-03 12:55:28 topi` has joined
 639 2012-06-03 13:04:08 D34TH has joined
 640 2012-06-03 13:06:29 Z0rZ0rZ0r has quit (Remote host closed the connection)
 641 2012-06-03 13:10:52 <BlueMatt> luke-jr: how much not-submitting-valid-blocks do you think you are seeing on eligius?
 642 2012-06-03 13:11:05 <BlueMatt> s/think/estimate/
 643 2012-06-03 13:13:53 rdponticelli has joined
 644 2012-06-03 13:14:20 t7 has quit (Ping timeout: 260 seconds)
 645 2012-06-03 13:19:43 copumpkin has quit (Ping timeout: 248 seconds)
 646 2012-06-03 13:21:04 twmz has joined
 647 2012-06-03 13:21:50 Joric has quit ()
 648 2012-06-03 13:21:50 copumpkin has joined
 649 2012-06-03 13:26:00 slush has quit (Ping timeout: 260 seconds)
 650 2012-06-03 13:28:53 username57913 has quit (Ping timeout: 246 seconds)
 651 2012-06-03 13:31:48 t7 has joined
 652 2012-06-03 13:32:11 username57913 has joined
 653 2012-06-03 13:36:40 copumpkin has quit (Ping timeout: 244 seconds)
 654 2012-06-03 13:39:43 copumpkin has joined
 655 2012-06-03 13:44:42 sacredchao has quit (Disconnected by services)
 656 2012-06-03 13:52:46 _W_ has quit (Excess Flood)
 657 2012-06-03 13:52:54 _W_ has joined
 658 2012-06-03 14:02:01 Zarutian has joined
 659 2012-06-03 14:11:59 minimoose has joined
 660 2012-06-03 14:12:37 PK_ has joined
 661 2012-06-03 14:13:15 PK_ is now known as PK
 662 2012-06-03 14:15:19 Zarutian has quit (Ping timeout: 256 seconds)
 663 2012-06-03 14:19:27 Zarutian has joined
 664 2012-06-03 14:22:26 <luke-jr> BlueMatt: impossible to detect, but hopefully none
 665 2012-06-03 14:23:39 <luke-jr> BlueMatt: however, Bitcoin in general has seen a lot of attacks aimed at pools that don't benefit the attacker directly, so it seems inevitable
 666 2012-06-03 14:24:03 <luke-jr> (or rather, there is a known way to detect it, but it's expensive an an arms race when implemented)
 667 2012-06-03 14:26:31 <BlueMatt> luke-jr: I was just wondering if you had compared expected generation based on share count to actual generation
 668 2012-06-03 14:26:42 <BlueMatt> and then compared to probability that your luck is at n
 669 2012-06-03 14:27:06 <luke-jr> BlueMatt: blocks are not that predictable.
 670 2012-06-03 14:27:26 <BlueMatt> no, but you can get a probability that there is nothing nefarious going on
 671 2012-06-03 14:27:34 <luke-jr> not significantly
 672 2012-06-03 14:27:47 <luke-jr> most of Eligius's runtime, we've been very "lucky"
 673 2012-06-03 14:28:12 <luke-jr> at present, we're about 600 BTC "unlucky"
 674 2012-06-03 14:28:24 <luke-jr> past "luck" peaked around 1200 BTC or so
 675 2012-06-03 14:28:40 <luke-jr> there is no meaningful way to get statistics when it swings this far
 676 2012-06-03 14:28:46 <BlueMatt> yea, afaik most pools tend to have pretty close to 100% "luck" over the long-run, so I have a hard time believing share withholding is an issue thats worth solving, really
 677 2012-06-03 14:29:26 <BlueMatt> over a year or more, you would notice anything more than like 5% of shares withheld, I would think
 678 2012-06-03 14:29:29 <BlueMatt> s/would/could
 679 2012-06-03 14:29:30 <luke-jr> if it isn't, it will someday.
 680 2012-06-03 14:29:58 <luke-jr> especially as centralized pooled mining phases out
 681 2012-06-03 14:31:45 RainbowDashh has quit (Quit: RainbowDashh)
 682 2012-06-03 14:33:06 wasabi has quit (Ping timeout: 244 seconds)
 683 2012-06-03 14:34:21 RainbowDashh has joined
 684 2012-06-03 14:39:39 <TD> hmm
 685 2012-06-03 14:39:45 <TD> luke-jr: p2pool seems to have stopped growing
 686 2012-06-03 14:39:51 <TD> luke-jr: what makes you think centralized mining will phase out?
 687 2012-06-03 14:40:11 <luke-jr> TD: it's inevitable IMO. and Eligius hasn't stopped growing.
 688 2012-06-03 14:40:30 <luke-jr> p2pool is just one pool. hardly a good statistic :P
 689 2012-06-03 14:40:34 <TD> heh
 690 2012-06-03 14:40:59 <TD> i guess they have exhausted the supply of people willing to dick about with python programs. either that or their consistently <100% luck is a put-off
 691 2012-06-03 14:41:01 <Eliel> luke-jr: looking at the hashrate graph, I find it hard to figure out how you come to that conclusion.
 692 2012-06-03 14:41:28 spiborg has joined
 693 2012-06-03 14:41:40 <luke-jr> TD: possible their consistently <100% luck is the attack ;)
 694 2012-06-03 14:41:48 <TD> huh
 695 2012-06-03 14:42:01 <TD> somebody might be attacking p2pool? i guess so .... only people i can imagine who'd do that are centralized pool operators
 696 2012-06-03 14:42:02 <luke-jr> Eliel: well, it was growing about 100 GH/s per month until that downtime thing
 697 2012-06-03 14:42:05 <TD> everyone else stands to benefit
 698 2012-06-03 14:42:52 <talpan> Hello. How can I get the bitcoin address of the sender, like satoshidice is doing it?
 699 2012-06-03 14:43:15 <luke-jr> TD: dunno,  haven't thought it through
 700 2012-06-03 14:43:18 <TD> ok
 701 2012-06-03 14:43:58 <luke-jr> TD: there *are* non-obvious ways to profit from block withholding attacks, however
 702 2012-06-03 14:44:07 <TD> hmm
 703 2012-06-03 14:44:07 <BlueMatt> TD/luke-jr: the discussion in #p2pool focuses on the huge orphan rates, which appears to be the source of much of the problem
 704 2012-06-03 14:44:08 <luke-jr> but PPLNS is immune to the one I know of in detail
 705 2012-06-03 14:44:13 <TD> ok
 706 2012-06-03 14:44:15 <TD> BlueMatt: thanks
 707 2012-06-03 14:44:19 <luke-jr> BlueMatt: really? interesting
 708 2012-06-03 14:44:22 <TD> BlueMatt: general perf issues then?
 709 2012-06-03 14:44:27 <luke-jr> I'd expect lower orphan rates really
 710 2012-06-03 14:44:28 <TD> talpan: satoshidice uses bitcoinj
 711 2012-06-03 14:44:44 <BlueMatt> it appears that people are just running bitcoind on low-power systems which cant handle it/are poorly peered
 712 2012-06-03 14:44:45 <TD> talpan: so they're just using the API that library provides. if you want to do it with bitcoind i think you have to wait for some more RPCs to be added?
 713 2012-06-03 14:45:18 <luke-jr> TD: does BitcoinJ ignore transactions that don't meet bitcoind fee rules?
 714 2012-06-03 14:45:37 <luke-jr> BlueMatt: so kinda an accidental form of block withholding?
 715 2012-06-03 14:45:39 <BlueMatt> luke-jr: I dunno, I just dont see it as nearly worth hard-forking to avoid the withhold-share issue...unless some data comes up which shows that its likely actually occurring in a meaningful way, that is
 716 2012-06-03 14:45:41 <talpan> Thank you, that's the reason I couldn't figure it out :) Thanks
 717 2012-06-03 14:46:00 <TD> bitcoinj has no fee support at all right now :( users fork the library to add it. it's one of my next top priorities. at any rate, bitcoinj cannot know the fee of an arbitrary transaction without recursively downloading all the connected transactions.
 718 2012-06-03 14:46:03 <TD> which it currently does not do
 719 2012-06-03 14:46:04 <BlueMatt> luke-jr: no, just working on stale work, you could correlate the two, but...not really
 720 2012-06-03 14:46:23 <luke-jr> BlueMatt: my point is that it's almost guaranteed to happen *someday* and therefore if we act now, we can leisurely schedule it for some time in the future
 721 2012-06-03 14:46:35 <BlueMatt> I disagree
 722 2012-06-03 14:46:41 <BlueMatt> its guaranteed to happen on some scale, sure
 723 2012-06-03 14:46:52 <BlueMatt> but if its 1% of most pools...so what?
 724 2012-06-03 14:46:53 <BlueMatt> anyway, gotta go
 725 2012-06-03 14:48:40 Clipse has quit (Ping timeout: 245 seconds)
 726 2012-06-03 14:51:53 wasabi has joined
 727 2012-06-03 14:52:10 p0s has joined
 728 2012-06-03 14:55:05 RainbowDashh has quit (Quit: RainbowDashh)
 729 2012-06-03 14:56:16 Diablo-D3 has quit (Ping timeout: 250 seconds)
 730 2012-06-03 14:56:32 RainbowDashh has joined
 731 2012-06-03 14:57:52 Rabbit67890 has joined
 732 2012-06-03 14:57:53 RainbowDashh has quit (Disconnected by services)
 733 2012-06-03 15:04:16 talpan has quit (Ping timeout: 248 seconds)
 734 2012-06-03 15:06:56 Rabbit67890 has quit (Read error: No route to host)
 735 2012-06-03 15:08:07 RainbowDashh has joined
 736 2012-06-03 15:09:27 stejin has joined
 737 2012-06-03 15:10:06 stejin has left ()
 738 2012-06-03 15:17:26 _W_ has quit (Excess Flood)
 739 2012-06-03 15:17:36 _W_ has joined
 740 2012-06-03 15:18:05 gribble has quit (Quit: brb)
 741 2012-06-03 15:18:26 RainbowDashh has quit (Ping timeout: 252 seconds)
 742 2012-06-03 15:18:50 gribble has joined
 743 2012-06-03 15:20:45 t7 has quit (Ping timeout: 245 seconds)
 744 2012-06-03 15:25:56 <luke-jr> ironically, it seems the "sendrawtx" JSON-RPC command doesn't work?
 745 2012-06-03 15:26:16 <wizkid057> ACK...
 746 2012-06-03 15:27:19 <wizkid057> it seems to verify the transaction is valid, has valid inputs, etc, gives the txid back as a result... but it never hits the network
 747 2012-06-03 15:30:55 wladston has joined
 748 2012-06-03 15:31:35 <wladston> how bitcoind accounts works ? anyone if familiar with it ?
 749 2012-06-03 15:32:06 <wladston> I wanted to know if it keeps track of confirmed and unconfirmed balances across internal transfers
 750 2012-06-03 15:33:52 <luke-jr> sipa: where can I get seeds.txt that hasn't been filtered? -.-
 751 2012-06-03 15:34:02 eoss has joined
 752 2012-06-03 15:34:18 <luke-jr> sipa: … and why are you filtering the latest 0.4 and 0.5? :/
 753 2012-06-03 15:38:18 <wladston> for example, if wallet A as 10 confirmed, and 5 unconfirmed, and it sends 11 to wallet B
 754 2012-06-03 15:38:28 <wladston> how much confirmed and unconfirmed will wallet B have ?
 755 2012-06-03 15:38:35 spiborg has left ()
 756 2012-06-03 15:40:54 RainbowDashh has joined
 757 2012-06-03 15:49:16 p0s has quit (Remote host closed the connection)
 758 2012-06-03 15:49:18 <gribble> New news from bitcoinrss: wizkid057 opened issue 1414 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1414>
 759 2012-06-03 15:55:36 random_cat__ has quit (Remote host closed the connection)
 760 2012-06-03 15:56:44 random_cat__ has joined
 761 2012-06-03 15:59:21 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
 762 2012-06-03 16:03:03 Zarutian has quit (Quit: Zarutian)
 763 2012-06-03 16:03:24 <wladston> from my tests here, it looks like transfer between internal wallets will not respect the confirmed/unconfirmed status from the money being transfered
 764 2012-06-03 16:04:19 Zarutian has joined
 765 2012-06-03 16:04:24 <wladston> for example, I have 1 confirmed and 1 unconfirmed at account w1, and I issue a move of 2 from w1 to w2.
 766 2012-06-03 16:04:49 <wladston> w2's balance will show 2 confirmed, with is just plain wrong
 767 2012-06-03 16:05:23 eoss has quit (Remote host closed the connection)
 768 2012-06-03 16:05:43 danieldaniel has joined
 769 2012-06-03 16:06:04 <wladston> should I fill a bug ?
 770 2012-06-03 16:07:15 freewil has quit (Quit: Leaving)
 771 2012-06-03 16:07:25 <wizkid057> not sure I understand what you've been getting at...
 772 2012-06-03 16:07:31 <wizkid057> you cant "send" confirmations...
 773 2012-06-03 16:12:14 eoss has joined
 774 2012-06-03 16:12:14 eoss has quit (Changing host)
 775 2012-06-03 16:12:14 eoss has joined
 776 2012-06-03 16:14:05 tower has quit (Ping timeout: 245 seconds)
 777 2012-06-03 16:15:53 <wladston> wizkid057: You can't send confirmations, but the money you send from an account is either confirmed or not, right ?
 778 2012-06-03 16:16:46 <wizkid057> once coins are sent, the transaction must be confirmed, regardless of whether the funds you're sending are confirmed already or not
 779 2012-06-03 16:16:48 danieldaniel has left ()
 780 2012-06-03 16:16:53 Zarutian has quit (Quit: Zarutian)
 781 2012-06-03 16:16:56 tower has joined
 782 2012-06-03 16:16:57 Clipse has joined
 783 2012-06-03 16:19:01 <wladston> wizkid057: I'm refering to internal transactions, between internal bitcoind accounts.
 784 2012-06-03 16:19:08 <wizkid057> doesnt matter
 785 2012-06-03 16:19:28 <wizkid057> the network still needs to confirm you moved the funds between accounts
 786 2012-06-03 16:19:33 <wizkid057> thus, resetting to 0
 787 2012-06-03 16:20:03 <wladston> wizkid057: it doesn't. the internal accounts moves are not brodcasted to the bitcoin network.
 788 2012-06-03 16:20:26 <wladston> wizkid057: see here https://en.bitcoin.it/wiki/Accounts_explained
 789 2012-06-03 16:21:02 <sipa> wizkid057: transfers between acounts are just adjusting local balances
 790 2012-06-03 16:21:33 <wizkid057> oh, we're talking about accounts, not addresses
 791 2012-06-03 16:21:36 <sipa> luke-jr: small bug, i lost my database, so i had to reset
 792 2012-06-03 16:21:45 <luke-jr> sipa: oh :<
 793 2012-06-03 16:22:09 * wizkid057 drinks more coffee
 794 2012-06-03 16:22:11 <luke-jr> sipa: it's sending replies from the wrong source IP for me :/
 795 2012-06-03 16:22:22 <wladston> guys, can you see the bug I'm taking about ?
 796 2012-06-03 16:22:40 <sipa> luke-jr: how so?
 797 2012-06-03 16:22:45 <wladston> I'm currently baking a paper describing a fix for it.
 798 2012-06-03 16:23:43 <wladston> I took about 4 days thinking about the problem every day to come up with the solution
 799 2012-06-03 16:24:08 <luke-jr> sipa: it's using the first IPv4 address on the interface, rather than the one that received the request
 800 2012-06-03 16:24:46 <luke-jr> wladston: accounts don't have coins, just balances.
 801 2012-06-03 16:25:19 <wladston> luke-jr: but it does have the confirmation status for the balances
 802 2012-06-03 16:25:25 MobiusL has quit (Ping timeout: 276 seconds)
 803 2012-06-03 16:25:30 <luke-jr> wladston: confirmations apply to coins, not balances
 804 2012-06-03 16:25:58 <wladston> luke-jr: so why the balance method has a minimum confirmation parameter ?
 805 2012-06-03 16:26:08 <luke-jr> no idea
 806 2012-06-03 16:26:16 <sipa> wladston: because it allows you to filter coins sent to it
 807 2012-06-03 16:26:17 <wladston> that is a bug, then
 808 2012-06-03 16:26:33 <sipa> this does not make much sense when you also have moves active
 809 2012-06-03 16:26:41 <wladston> sipa: I did not send any coins to the wallet address
 810 2012-06-03 16:26:51 <wladston> sipa: but the balance is still positive
 811 2012-06-03 16:26:56 <wladston> from my move
 812 2012-06-03 16:27:09 <sipa> moves are just always counted
 813 2012-06-03 16:27:17 <wladston> sipa: why ?
 814 2012-06-03 16:27:27 <sipa> how can you not count them?
 815 2012-06-03 16:27:44 <wladston> sipa:  you can correctly track their confirmation status and count that
 816 2012-06-03 16:27:57 <sipa> moves.are always infinitely confirmed
 817 2012-06-03 16:28:00 <luke-jr> wladston: moves don't have confirmations in any sense of the word
 818 2012-06-03 16:28:24 <luke-jr> all it does is set AccountFrom -= amount, AccountTo += amount
 819 2012-06-03 16:28:29 <luke-jr> you can even make accounts negative
 820 2012-06-03 16:28:31 <sipa> it's just decreasing the balance of one account, and increasing that of another
 821 2012-06-03 16:28:41 <wladston> do you think this is a good design choice, to have moves always count as confirmed balance even when it comes from an unconfirmed source ?
 822 2012-06-03 16:28:54 <luke-jr> wladston: it doesn't "come from" anywhere
 823 2012-06-03 16:29:02 <sipa> moves do not come from any source, except the account
 824 2012-06-03 16:29:15 <sipa> there are absolutrly no coins involved in a move
 825 2012-06-03 16:29:49 <luke-jr> sipa: maybe we should add "changebalance" to assign/increment/decrement accounts without any interaction with other accounts ;)
 826 2012-06-03 16:29:51 <luke-jr> just to stress this
 827 2012-06-03 16:29:57 <wladston> I get what you are saying. It's just irrelevant for you to see if a move involves real confirmed coins or not
 828 2012-06-03 16:30:07 <luke-jr> wladston: no
 829 2012-06-03 16:30:12 <luke-jr> there are NO COINS INVOLVED
 830 2012-06-03 16:30:23 <sipa> as i said, combining moves with confirmations selections leads to meaningless results, but it is well-defined
 831 2012-06-03 16:30:28 <luke-jr> you can have an empty wallet and still move 100 BTC from one account to another
 832 2012-06-03 16:30:38 <luke-jr> the from account will then have a negative balance
 833 2012-06-03 16:31:09 <wladston> I understand. I was in need of a way to move REAL COINS within internal accounts
 834 2012-06-03 16:31:22 <wizkid057> wladston: sendtoaddress ?
 835 2012-06-03 16:31:33 <luke-jr> wladston: that could get expensive.
 836 2012-06-03 16:31:36 <wladston> without broadcasting the transaction
 837 2012-06-03 16:31:40 <wizkid057> sipa: I notice you ACK'd the sendrawtx command pull req... however, it doesnt broadcast no matter what I do. did you have a different experience?
 838 2012-06-03 16:31:41 <wladston> just internally
 839 2012-06-03 16:31:48 <luke-jr> oh
 840 2012-06-03 16:31:51 <luke-jr> I think I see what you mean
 841 2012-06-03 16:31:55 <sipa> as are in no way tied to an account, tht doesn't make sense
 842 2012-06-03 16:32:08 <luke-jr> sipa: they could be
 843 2012-06-03 16:32:24 <luke-jr> he basically wants a completely new account design
 844 2012-06-03 16:32:25 <sipa> yes, incoming coins are, actually
 845 2012-06-03 16:32:36 <sipa> i think he wants multiwallet support
 846 2012-06-03 16:32:46 <luke-jr> sipa: you can't move individual coins between wallets
 847 2012-06-03 16:32:46 <sipa> instead of accounts within a wallet
 848 2012-06-03 16:32:47 <wladston> luke-jr: I did this design internally in my application
 849 2012-06-03 16:33:02 JZavala has joined
 850 2012-06-03 16:33:16 <sipa> luke-jr: it requires a bitcoin transaction of course
 851 2012-06-03 16:33:17 _Fireball has quit (Read error: No route to host)
 852 2012-06-03 16:33:19 <luke-jr> sipa: no
 853 2012-06-03 16:33:28 <sipa> right, i see, there is another design possible
 854 2012-06-03 16:33:36 <luke-jr> it might, if he has a single 5 BTC coin and wants to move only 2.5 BTC to another account
 855 2012-06-03 16:33:46 <sipa> where coins remain tied to the account they were received with
 856 2012-06-03 16:34:06 <wladston> sipa: EXACTLY
 857 2012-06-03 16:34:17 <wladston> sipa: that's what I did here
 858 2012-06-03 16:34:19 <luke-jr> wladston: I think it'd be ugly for users
 859 2012-06-03 16:34:22 _Fireball has joined
 860 2012-06-03 16:34:28 <wladston> the interface would be the same
 861 2012-06-03 16:34:32 <wizkid057> seems like it'd be an over-complication of the system
 862 2012-06-03 16:34:33 <wladston> same api calls
 863 2012-06-03 16:34:36 <sipa> accounts are already very hard to grasp
 864 2012-06-03 16:34:38 <luke-jr> "why do I need a transaction to move 5 BTC, but not to move 5.4933344 BTC⁇?"
 865 2012-06-03 16:35:20 <luke-jr> actually
 866 2012-06-03 16:35:45 <luke-jr> I suppose a sufficiently complex implementation could flag a coin as "partly account A, and partly account B" and then use it in the next transaction to split it
 867 2012-06-03 16:35:57 <wladston> my problem is the following : I want to accept zero confirmation coins, and let users play with then, sending then to each other (internally). But I only want to let anyone withdraw coins if the source was confirmed.
 868 2012-06-03 16:35:58 <wizkid057> ...
 869 2012-06-03 16:36:29 <sipa> wizkid057: to be honest, i only looked at the code and compiled it
 870 2012-06-03 16:36:33 <wladston> luke-jr: yes! but it's actually no that complex to implement
 871 2012-06-03 16:37:03 TD has quit (Quit: TD)
 872 2012-06-03 16:37:05 <sipa> wizkid057: i suppose it just broadcasts once, as it doesn't get associated with your wallet, it isn't rebroadcasted
 873 2012-06-03 16:37:20 <wladston> so my users would know if the coins they are playing with are confirmed or not.
 874 2012-06-03 16:37:24 <sipa> Ukto: what do you need me for?
 875 2012-06-03 16:39:10 <wizkid057> sipa: well, to test before I posted my issue, i connected bitcoind to only blockchain.info, sent a raw tx, didnt appear on there... second, connected two local bitcoinds together using addnode, sent coins to an address known to one from the other using sendrawtx and it never showed, either... so, i'm at a loss
 876 2012-06-03 16:39:13 <luke-jr> wladston: do you have a patch?
 877 2012-06-03 16:39:55 <wladston> luke-jr: I developed that at the application level, using raw address calls.
 878 2012-06-03 16:40:25 <wladston> luke-jr: my design could easily be ported inside bitcoind. the thing is, I never even looked at bitcoind source :)
 879 2012-06-03 16:40:40 <wizkid057> i admittedly do not believe i've studied the bitcoin client sufficiently enough to fix the issue myself
 880 2012-06-03 16:40:44 MobiusL has joined
 881 2012-06-03 16:41:04 <wladston> luke-jr: the technique a bit hard to grasp, so I'm writing the scientific-looking paper first
 882 2012-06-03 16:43:41 <wizkid057> oddly, the TX "is" in the local "getmemorypool" for that client
 883 2012-06-03 16:43:47 <wizkid057> but not the receiving client
 884 2012-06-03 16:45:32 <Ukto> sipa: is adding 1~3 seconds to report work from a miner to a pool worthy of being the excuse of rejects?
 885 2012-06-03 16:45:52 <Ukto> esp. with LP enabled
 886 2012-06-03 16:51:34 graingert has quit (Remote host closed the connection)
 887 2012-06-03 16:53:57 wladston has quit (Quit: Leaving.)
 888 2012-06-03 16:55:00 copumpkin has quit (Quit: Computer has gone to sleep.)
 889 2012-06-03 16:55:04 <sipa> wizkid057: i'll have a look at it later
 890 2012-06-03 16:55:25 <wizkid057> np, thx
 891 2012-06-03 16:55:27 <sipa> Ukto: hmm, there are a lot of people here who know more about mining
 892 2012-06-03 16:55:51 <BlueMatt> wizkid057: are you sure you arent making an orphan?
 893 2012-06-03 16:55:57 <BlueMatt> wizkid057: what does debug.log say?
 894 2012-06-03 16:57:30 <sipa> if it is in his mempool, it is not an orphan
 895 2012-06-03 16:57:43 Internet13 has quit (Quit: Leaving)
 896 2012-06-03 16:57:47 <BlueMatt> oh, didnt read that, sorry
 897 2012-06-03 16:58:17 <sipa> and if it is in his mempool, it should certainly be relayed
 898 2012-06-03 16:58:34 <BlueMatt> mempool doesnt relay, but there is a RelayInventory call in sendrawtx
 899 2012-06-03 16:59:07 <wizkid057> guess i should recompile with debugging :P
 900 2012-06-03 16:59:10 <BlueMatt> anyway, also, check chub
 901 2012-06-03 16:59:13 * BlueMatt -> dinner
 902 2012-06-03 17:03:04 <MrTiggr> *cough* ..... longtime watcher first-time poster ...
 903 2012-06-03 17:03:09 <MrTiggr>  mebbe u guys can help me .......
 904 2012-06-03 17:03:09 <MrTiggr> <chmod755> ???
 905 2012-06-03 17:03:10 <MrTiggr> <MrTiggr> i wanna fingerprint the wallet format
 906 2012-06-03 17:03:10 <MrTiggr> <MrTiggr> and create a SNORT rule
 907 2012-06-03 17:03:10 <MrTiggr> <MrTiggr> to stop exfiltration of wallets from servers
 908 2012-06-03 17:03:10 <MrTiggr> <MrTiggr> look at all outbound packets
 909 2012-06-03 17:03:12 <MrTiggr> <MrTiggr> see fingerprint
 910 2012-06-03 17:03:14 <MrTiggr> <MrTiggr> STOP
 911 2012-06-03 17:03:16 <MrTiggr> <MrTiggr> HALT
 912 2012-06-03 17:03:18 <MrTiggr> <MrTiggr> DIE
 913 2012-06-03 17:03:48 erle- has quit (Quit: erle-)
 914 2012-06-03 17:03:54 erle- has joined
 915 2012-06-03 17:05:25 Internet13 has joined
 916 2012-06-03 17:09:30 <Tuxavant> MrTiggr, it's a noble cause, but all it takes to circumvent is encoding the file before exfilration
 917 2012-06-03 17:10:18 <Tuxavant> if I was exfiltrating any data, I'd be XORing it before hand and I'm not even that smart
 918 2012-06-03 17:10:30 elkingrey has joined
 919 2012-06-03 17:13:04 <MrTiggr> of, i would be too
 920 2012-06-03 17:13:21 <MrTiggr> but you can make common base64/xor patter matches if you have a fingerprint
 921 2012-06-03 17:13:34 <MrTiggr> i know,i know ... they cud just tomwilliams the keys out too
 922 2012-06-03 17:13:38 <MrTiggr> and thats harder still
 923 2012-06-03 17:14:05 <MrTiggr> but - for noobie/mybitcoinica operators, a set of snorts wud be a good sart no ?
 924 2012-06-03 17:15:11 copumpkin has joined
 925 2012-06-03 17:15:20 <MrTiggr> (pardon my fingrfail tonight .. its late)
 926 2012-06-03 17:15:50 OpenOcean has quit (Ping timeout: 260 seconds)
 927 2012-06-03 17:16:06 <luke-jr> sipa: https://github.com/sipa/bitcoin-seeder/pulls
 928 2012-06-03 17:17:07 OpenOcean has joined
 929 2012-06-03 17:20:40 <Tuxavant> MrTiggr, I think it's worth doing if for nothing but the experience, but I'm just not a fan of signature based systems so I dismiss it easily... But dont let me discourage you from giving it a shot. It's a berkly DB so you might find quite a lot of collisions unless you dig deep into the bitcoin specific tables
 930 2012-06-03 17:24:05 rdponticelli has quit (Ping timeout: 245 seconds)
 931 2012-06-03 17:24:44 <luke-jr> MrTiggr: nevermind that none of the cracking has stolen wallet.dat files…
 932 2012-06-03 17:25:32 <luke-jr> sipa: OK, I just switched my DNS seed from a CNAME to jgarzik to an actual bitcoin-seeder instance
 933 2012-06-03 17:27:22 <MrTiggr> OK, thanks guys ... what about using snort rules to detect the exfiltration of your own keys then ?   id NEVER suggest including your keys in a sort rule .. but .. what about PART of it ? .... luke-jr Tuxavant ?
 934 2012-06-03 17:27:53 <luke-jr> MrTiggr: all the crackers have used bitcoind to send a transaction to an address they control
 935 2012-06-03 17:28:19 <luke-jr> they don't care about private keys
 936 2012-06-03 17:28:24 <MrTiggr> luke-jr: so it will contain your own source id
 937 2012-06-03 17:28:35 <BlueMatt> luke-jr: sure they do, there has been malware that steals all of wallet.dat
 938 2012-06-03 17:28:46 <BlueMatt> luke-jr: I havent actually seen malware that steals coins directly
 939 2012-06-03 17:28:46 <luke-jr> BlueMatt: I'm not talking about virii
 940 2012-06-03 17:28:47 <MrTiggr> snort rules outbound to detect use of your wallet id ?
 941 2012-06-03 17:28:54 <MrTiggr> im just brainstorming here
 942 2012-06-03 17:29:00 <MrTiggr> sick of mopping up the mess
 943 2012-06-03 17:29:02 wladston has joined
 944 2012-06-03 17:29:05 <MrTiggr> wud rather find a prevention
 945 2012-06-03 17:29:11 <luke-jr> BlueMatt: only big merchant/exchange/etc sites would be using firewalls of this calibur
 946 2012-06-03 17:29:12 <BlueMatt> MrTiggr: sadly wallets are pretty commonly-used fingerprints, they are a bdb databse
 947 2012-06-03 17:29:26 <BlueMatt> MrTiggr: you might try fingerprinting private keys
 948 2012-06-03 17:29:27 <MrTiggr> yer .. but theres gotta be some set of unique rules
 949 2012-06-03 17:29:34 <MrTiggr> hrrm
 950 2012-06-03 17:29:56 <BlueMatt> oh, wait, do we store CSecrets now, or private keys still?
 951 2012-06-03 17:30:06 mmoya has quit (Ping timeout: 250 seconds)
 952 2012-06-03 17:30:23 <BlueMatt> luke-jr: no, they should be storing their wallet offline, so no firewall is required...
 953 2012-06-03 17:30:54 wladston has quit (Client Quit)
 954 2012-06-03 17:31:11 <luke-jr> BlueMatt: exchanges at least need online wallets
 955 2012-06-03 17:31:37 <luke-jr> MrTiggr: besides, they should be using wallet encryption
 956 2012-06-03 17:32:27 <MrTiggr> oh, i KNOW THEY should be
 957 2012-06-03 17:32:29 <MrTiggr> but srs
 958 2012-06-03 17:32:37 <MrTiggr> we know this is the wild-west luke-jr
 959 2012-06-03 17:32:41 <MrTiggr> ;)
 960 2012-06-03 17:33:16 <BlueMatt> luke-jr: no they dont
 961 2012-06-03 17:33:34 <luke-jr> MrTiggr: someone who doesn't, won't run a firewall rule either
 962 2012-06-03 17:33:36 <BlueMatt> luke-jr: they can sneakernet withdraws
 963 2012-06-03 17:33:43 <luke-jr> BlueMatt: LOL
 964 2012-06-03 17:33:52 <BlueMatt> I said can, not should
 965 2012-06-03 17:34:02 <BlueMatt> though I would argue for large withdraws, they probably should
 966 2012-06-03 17:34:35 JZavala has quit (Ping timeout: 252 seconds)
 967 2012-06-03 17:34:57 <MrTiggr> guys, dont shoot the messenger ... like i sed, im sick of mopping up the mess, wondering if thres a way to stop it in a preventative way IDS/IPS style
 968 2012-06-03 17:35:07 <MrTiggr> all good points
 969 2012-06-03 17:36:12 <BlueMatt> anyway, the point is, its quite hard, probably impossible to do even a good job stopping it ids style, doing it properly to begin with isnt /that/ hard, and saves all the headache later on
 970 2012-06-03 17:36:52 <BlueMatt> sadly, no one seems to understand that just having one online wallet and one offline one with less cash isnt enough to do it "properly"
 971 2012-06-03 17:37:00 <MrTiggr> kk, thnx ... better not waste my bandwidth there .. is the general response ... D:
 972 2012-06-03 17:37:03 <BlueMatt> atleast not several major people who whould
 973 2012-06-03 17:37:05 <MrTiggr> BlueMatt: i know :(
 974 2012-06-03 17:37:16 <BlueMatt> I do think its a cool idea
 975 2012-06-03 17:37:19 <MrTiggr> you can lead a horse to water... but you cant make him enjoiy the view
 976 2012-06-03 17:37:29 <MrTiggr> ;)
 977 2012-06-03 17:37:33 <BlueMatt> yep
 978 2012-06-03 17:40:51 rdponticelli has joined
 979 2012-06-03 17:43:40 Z0rZ0rZ0r has joined
 980 2012-06-03 17:51:48 Matt_von_Mises has joined
 981 2012-06-03 17:51:52 hnz has quit ()
 982 2012-06-03 17:55:54 <Matt_von_Mises> For transaction output values, how is the sign represented? The serialisation code goes over my head completely.
 983 2012-06-03 17:57:13 Lexa has quit (Quit: Lexa)
 984 2012-06-03 17:58:05 wladston has joined
 985 2012-06-03 18:00:16 rdponticelli_ has joined
 986 2012-06-03 18:00:46 rdponticelli has quit (Ping timeout: 245 seconds)
 987 2012-06-03 18:01:52 rdponticelli_ is now known as rdponticelli
 988 2012-06-03 18:06:49 Clipse has quit (Quit: Clipse)
 989 2012-06-03 18:07:31 ThomasV has joined
 990 2012-06-03 18:08:35 copumpkin is now known as catholipumpkin
 991 2012-06-03 18:09:59 catholipumpkin is now known as copumpkin
 992 2012-06-03 18:10:19 Lexa has joined
 993 2012-06-03 18:16:11 stalled has quit (Ping timeout: 244 seconds)
 994 2012-06-03 18:16:55 guruvan has quit (Quit: Later!)
 995 2012-06-03 18:23:05 Skaag has quit (Read error: Connection reset by peer)
 996 2012-06-03 18:23:25 Skaag has joined
 997 2012-06-03 18:27:01 Turingi has quit (Read error: Connection reset by peer)
 998 2012-06-03 18:33:56 OneFixt has quit (Remote host closed the connection)
 999 2012-06-03 18:34:47 da2ce715 has joined
1000 2012-06-03 18:35:05 Joric has joined
1001 2012-06-03 18:37:25 da2ce7 has quit (Ping timeout: 245 seconds)
1002 2012-06-03 18:37:40 Lexa has quit (Read error: Connection reset by peer)
1003 2012-06-03 18:38:15 OneFixt has joined
1004 2012-06-03 18:45:03 <luke-jr> sipa: ping
1005 2012-06-03 18:46:05 da2ce715 has quit (Read error: Connection reset by peer)
1006 2012-06-03 18:46:26 RainbowDashh has quit (Quit: RainbowDashh)
1007 2012-06-03 18:47:48 da2ce715 has joined
1008 2012-06-03 18:48:30 RainbowDashh has joined
1009 2012-06-03 18:49:37 bayleef has joined
1010 2012-06-03 18:54:44 da2ce7 has joined
1011 2012-06-03 18:56:48 <luke-jr> sipa: bayleef's client is stuck on block download, and his debug.log suggests he isn't even TRYING to get more: http://failbox.co.cc/debug.log
1012 2012-06-03 18:57:09 <luke-jr> hmm
1013 2012-06-03 18:57:15 da2ce715 has quit (Ping timeout: 240 seconds)
1014 2012-06-03 18:57:23 <luke-jr> bayleef: I presume you tried restarting your client?
1015 2012-06-03 18:58:10 <luke-jr> bayleef: if not, try that first; if so, try https://bitcointalk.org/?topic=82610
1016 2012-06-03 19:00:00 <gmaxwell> luke-jr: how long has he been stuck?
1017 2012-06-03 19:00:22 <gmaxwell> luke-jr: you'll stop pulling until the next block if the prior peer you were pulling from goes away.
1018 2012-06-03 19:00:46 <luke-jr> "It also hasn't downloaded any blocks for several days."
1019 2012-06-03 19:01:08 <gmaxwell> oh.
1020 2012-06-03 19:01:40 <luke-jr> [18:22:08] <bayleef> So I'm running bitcoind 0.6.2, and it says that either me or someone else needs to upgrade. It also hasn't downloaded any blocks for several days. Any idea what's going on?
1021 2012-06-03 19:01:42 <luke-jr> in #bitcoin
1022 2012-06-03 19:02:07 <luke-jr> gmaxwell: BTW, I PM'd you
1023 2012-06-03 19:02:53 silp has joined
1024 2012-06-03 19:04:42 silpee has quit (Ping timeout: 265 seconds)
1025 2012-06-03 19:08:11 wladston1 has joined
1026 2012-06-03 19:10:27 sgornick has quit (Quit: Ex-Chat)
1027 2012-06-03 19:11:46 <bayleef> luke-jr: Restarting just gave me the same results, building the test bitcoind now
1028 2012-06-03 19:11:59 wladston has quit (Ping timeout: 244 seconds)
1029 2012-06-03 19:15:40 sgornick has joined
1030 2012-06-03 19:16:35 saieko has quit (Ping timeout: 260 seconds)
1031 2012-06-03 19:18:31 saieko has joined
1032 2012-06-03 19:20:17 <BlueMatt> bayleef: have you tried running with -checkblocks ?
1033 2012-06-03 19:21:06 <luke-jr> BlueMatt: that makes sense if the blocks are being rejected
1034 2012-06-03 19:21:11 <luke-jr> but they're not even downloading
1035 2012-06-03 19:23:03 <BlueMatt> luke-jr: Im not sure about the previous run, but the one start of bitcoin I see in that debug.log looks like a bad peer
1036 2012-06-03 19:23:21 <BlueMatt> afaict it never responds to "askfor block 00000000000006da5742   0"
1037 2012-06-03 19:25:03 <BlueMatt> in fact, that pattern appears before the restart...
1038 2012-06-03 19:25:05 <BlueMatt> hmmm...
1039 2012-06-03 19:30:32 <BlueMatt> on a related note, can we start logging getblocks the same way we do askfor ?
1040 2012-06-03 19:34:10 RainbowDashh has quit (Quit: RainbowDashh)
1041 2012-06-03 19:38:16 rdponticelli has quit (Ping timeout: 245 seconds)
1042 2012-06-03 19:38:28 tyn has joined
1043 2012-06-03 19:38:45 RazielZ has quit (Ping timeout: 260 seconds)
1044 2012-06-03 19:43:33 tyn has quit (Ping timeout: 252 seconds)
1045 2012-06-03 19:45:36 hnz has joined
1046 2012-06-03 19:45:47 tyn has joined
1047 2012-06-03 19:47:05 RazielZ has joined
1048 2012-06-03 19:47:53 <BlueMatt> bayleef: can you run with -debug for a minute or two and post the end of debug.log?
1049 2012-06-03 19:52:17 <bayleef> sorry for the slow response... I ran the new bitcoind, it started upgrading my database, and everything went all unresponsive and stuff. Bitcoind seems to have died
1050 2012-06-03 19:53:30 <BlueMatt> yea next-test can be a bit...unstable
1051 2012-06-03 19:54:56 <bayleef> So what now? Should I try again? From looking at the debug log it seems to have been in, as GitHub would say, hardcore upgrading action
1052 2012-06-03 19:55:15 <BlueMatt> can you try again with 0.6.2 with -debug
1053 2012-06-03 19:55:29 <bayleef> kk
1054 2012-06-03 19:56:36 <BlueMatt> luke-jr: why do you still list spesmilo in your sig...whens the last time it was updated?
1055 2012-06-03 19:59:22 elkingrey has quit (Quit: Leaving)
1056 2012-06-03 19:59:40 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
1057 2012-06-03 20:02:13 datagutt has quit (Ping timeout: 265 seconds)
1058 2012-06-03 20:02:49 Z0rZ0rZ0r has quit (Quit: Leaving)
1059 2012-06-03 20:03:15 ThomasV has quit (Ping timeout: 240 seconds)
1060 2012-06-03 20:04:04 Diapolo has joined
1061 2012-06-03 20:08:10 <bayleef> have an 11mb debug.log http://failbox.co.cc/debug.log.lzma
1062 2012-06-03 20:09:55 <BlueMatt> thanks
1063 2012-06-03 20:10:16 <luke-jr> ouch, forgot next-test had jgarzik's blockchain upgrade stuff
1064 2012-06-03 20:10:42 <luke-jr> BlueMatt: you have binaries of master, right?
1065 2012-06-03 20:11:06 <luke-jr> BlueMatt: dunno, sigs can't be updated without losing images anymore :/
1066 2012-06-03 20:11:30 <BlueMatt> luke-jr: master bins are at http://jenkins.bluematt.me/job/Bitcoin/ws/
1067 2012-06-03 20:11:52 <luke-jr> bayleef: all the same warnings as next-test apply, but try BlueMatt's build there
1068 2012-06-03 20:12:08 freewil has joined
1069 2012-06-03 20:12:16 <BlueMatt> do we not print args in debug.log?
1070 2012-06-03 20:12:30 <BlueMatt> we should
1071 2012-06-03 20:13:00 * luke-jr concurs
1072 2012-06-03 20:13:14 <luke-jr> inclduing those from config file
1073 2012-06-03 20:13:24 <BlueMatt> yea
1074 2012-06-03 20:13:37 <BlueMatt> well minus rpcpassword, rpcuser, etc
1075 2012-06-03 20:14:33 paraipan has quit (Remote host closed the connection)
1076 2012-06-03 20:14:55 <BlueMatt> luke-jr: that said, making him upgrade his db did result in an interesting debug.log..."ProcessBlock: ORPHAN BLOCK, prev=00000000000000000000"
1077 2012-06-03 20:15:09 <BlueMatt> genisis is considered orphan...
1078 2012-06-03 20:16:10 <luke-jr> BlueMatt: that was a bug in jgarzik's branch :p
1079 2012-06-03 20:16:27 <luke-jr> actually
1080 2012-06-03 20:16:36 <luke-jr> the build I linked shouldn't have had it…
1081 2012-06-03 20:16:43 <BlueMatt> oh...
1082 2012-06-03 20:17:09 Nachtwind has joined
1083 2012-06-03 20:17:38 <Nachtwind> hi.. is there any known problem with windows qt bitcoin and sendmany? It just doesnt seem to work. Downloaded the most recent binary
1084 2012-06-03 20:18:21 <luke-jr> confirmed: it's not in 20120519
1085 2012-06-03 20:18:32 <luke-jr> bayleef: what did you download exactly? O.o
1086 2012-06-03 20:18:50 <luke-jr> Nachtwind: be more specific on "doesnt seem to work"
1087 2012-06-03 20:19:31 <Nachtwind> trying to use sendmany via php using the normal rpcclient library and all i get is 500 Server error with the same code people on linux can use
1088 2012-06-03 20:20:17 dvide has quit ()
1089 2012-06-03 20:20:24 meLon has joined
1090 2012-06-03 20:20:31 <meLon> I'm having a hell of a time running bitcoind as cli daemon under a different user using this init.d script: https://bitcointalk.org/?topic=965.0b  Even after changing the CHUID settings, the script attempts to find bitcoind.conf in *my* directory vs the bitcoin user, so I am assuming the CHUID setting isn't working/it's running as the wrong user.  Any suggestions?
1091 2012-06-03 20:20:34 <luke-jr> Nachtwind: what's the command you're using?
1092 2012-06-03 20:21:01 <luke-jr> meLon: init.d scripts need to be run as root
1093 2012-06-03 20:21:09 <bayleef> Oops... Cloned and built this git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git
1094 2012-06-03 20:21:36 <Nachtwind> $cBitcoin -> sendmany("", $to); where array is just $to[address] = floatval(amount)
1095 2012-06-03 20:21:40 <luke-jr> bayleef: oh, you're compiling? just build git master then
1096 2012-06-03 20:21:49 <meLon> That's why I'm really confused luke-jr.  I'm running sudo /etc/init.d/bitcoind restart, but it's looking in *my* home dir for the conf file >_<
1097 2012-06-03 20:21:56 <BlueMatt> meLon: try sudo -H
1098 2012-06-03 20:22:21 <meLon> Thanks BlueMatt, now it's using root's home directory >_<
1099 2012-06-03 20:22:27 <luke-jr> lol
1100 2012-06-03 20:22:39 <luke-jr> that means it's runnign as root
1101 2012-06-03 20:22:39 <meLon> I've created the user 'bitcoin' who I would like to run bitcoind, instead of my user
1102 2012-06-03 20:22:47 <BlueMatt> dont run it as root...
1103 2012-06-03 20:23:14 <meLon> CHUID=bitcoin:bitcoin
1104 2012-06-03 20:23:25 <BlueMatt> is it running as user bitcoin:bitcoin?
1105 2012-06-03 20:23:56 <meLon> I am unable to determine that 100% BlueMatt, but I believe it is not, since it's looking in other home directories for the .conf file
1106 2012-06-03 20:24:08 <tcatm_> What initscript are you using?
1107 2012-06-03 20:24:15 <BlueMatt> home directory != user its running as (as sudo -H just proved ;) )
1108 2012-06-03 20:24:17 <luke-jr> [20:17:00] <meLon> I'm having a hell of a time running bitcoind as cli daemon under a different user using this init.d script: https://bitcointalk.org/?topic=965.0b  Even after changing the CHUID settings, the script attempts to find bitcoind.conf in *my* directory vs the bitcoin user, so I am assuming the CHUID setting isn't working/it's running as the wrong user.  Any suggestions?
1109 2012-06-03 20:25:39 talpan has joined
1110 2012-06-03 20:26:03 <meLon> http://pastie.org/private/xafcb9fqpepmgiynkrtr1q
1111 2012-06-03 20:26:42 <BlueMatt> meLon: can you change the initscript to just run like id or whoami?
1112 2012-06-03 20:26:43 <talpan> don't run bitcoin as root
1113 2012-06-03 20:26:57 <meLon> Im not trying to talpan...
1114 2012-06-03 20:27:02 <tcatm_> meLon: try prefixing start-stop-daemon with HOME=/home/bitcoin/ (or wherever it should look)
1115 2012-06-03 20:27:05 <BlueMatt> actually, nvm you arent running as root
1116 2012-06-03 20:27:15 <BlueMatt> or it wouldnt get Permission denied
1117 2012-06-03 20:27:48 <talpan> ah sorry, it is in .root: permission denied, you don't have the right do read/write .root
1118 2012-06-03 20:27:58 <meLon> BlueMatt: I did 'echo $NAME' and 'sudo /etc...' reported *my* name whereas 'sudo -H ...' reported *root*
1119 2012-06-03 20:27:59 <tcatm_> start-stop-daemon doesn't change enviroment settings so $HOME is likely still /root when running the binary
1120 2012-06-03 20:28:00 <talpan> *root
1121 2012-06-03 20:28:47 <tcatm_> Or better yet: Specify the exact location of the datadir
1122 2012-06-03 20:28:54 Diapolo has left ()
1123 2012-06-03 20:28:57 <meLon> If I knew how to do that....
1124 2012-06-03 20:29:11 Karmaon has quit (Quit: WeeChat 0.3.8-rc1)
1125 2012-06-03 20:29:13 <tcatm_> (and use SELinux to restrict access to wallet.dat to the bitcoind started by init!)
1126 2012-06-03 20:29:35 <meLon> Is the post I linked not the most up-to-date/recommended init script?
1127 2012-06-03 20:29:36 <talpan> bitcoind -datadir=/what/ever
1128 2012-06-03 20:30:05 <talpan> or something similiar, but you have to use -datadir
1129 2012-06-03 20:31:34 <meLon> DAEMON=/usr/bin/$name
1130 2012-06-03 20:31:36 OneFixt has quit (Ping timeout: 245 seconds)
1131 2012-06-03 20:31:47 <meLon> DAEMON_ARGS=-daemon -datadir=/home/bitcoin/.bitcoin
1132 2012-06-03 20:33:06 Phoebus has quit (Remote host closed the connection)
1133 2012-06-03 20:33:26 <meLon> Not working :\
1134 2012-06-03 20:33:38 <BlueMatt> bayleef: do you mind running bitcoind with -detachdb, then quitting (just so it finishes loading and then quits, dont need more) and then lzmaing your .bitcoin/blk* and uploading it somewhere?
1135 2012-06-03 20:33:43 Phoebus has joined
1136 2012-06-03 20:34:08 Karmaon has joined
1137 2012-06-03 20:34:15 <luke-jr> BlueMatt: seems to me the obvious thing to do first is him try git master to see if sipa's fix helps
1138 2012-06-03 20:34:24 <BlueMatt> which one?
1139 2012-06-03 20:34:39 <BlueMatt> sorry, I wanst aware there was a related fix, try master first
1140 2012-06-03 20:34:40 <luke-jr> 385f730 (sipa/unstuck, origin-pull/1315/head) Hopefully final fix for the stuck blockchain issue
1141 2012-06-03 20:34:49 <BlueMatt> oh, I thought that was 0.6.2
1142 2012-06-03 20:35:02 <luke-jr> no, 0.6.2 was just addrman
1143 2012-06-03 20:35:07 Karmaon has quit (Client Quit)
1144 2012-06-03 20:35:17 <BlueMatt> bayleef: nevermind, can you try downloading bitcoind/-qt[.exe] from http://jenkins.bluematt.me/job/Bitcoin/ws/ and trying that?
1145 2012-06-03 20:35:22 <luke-jr> at that time, the unstuck didn't work, so it got deferred
1146 2012-06-03 20:35:43 <BlueMatt> bayleef: if that doesnt get you unstuck, would you mind running with -detachdb
1147 2012-06-03 20:35:50 Zarutian has joined
1148 2012-06-03 20:35:51 <BlueMatt> and uploading
1149 2012-06-03 20:38:53 Clipse has joined
1150 2012-06-03 20:40:51 <wizkid057> not sure if its related, but, I had an issue with bitcoind downloading blocks when getting my raspberry pi version compiled
1151 2012-06-03 20:40:59 <wizkid057> was because of a problem with my libdb
1152 2012-06-03 20:42:17 <meLon> Sweet luke-jr BlueMatt.  I was able to get it to work, and now I just have to figure out this boost permission issue :D  Thanks
1153 2012-06-03 20:42:31 <meLon> EXCEPTION: N5boost12interprocess22interprocess_exceptionE :P
1154 2012-06-03 20:43:52 Nachtwind has left ("Verlassend")
1155 2012-06-03 20:45:51 OneFixt has joined
1156 2012-06-03 20:47:16 <tcatm_> What's the current state of multiple wallets support in bitcoin-qt?
1157 2012-06-03 20:47:44 <talpan> "none", you to rename each wallet and restart bitcoin
1158 2012-06-03 20:47:53 minimoose has quit (Quit: minimoose)
1159 2012-06-03 20:48:01 <talpan> 1. shut down bitcoin, 2. rename wallet, 3. start bitcoin
1160 2012-06-03 20:49:09 <meLon> You guys ever seen this? http://pastie.org/4021380
1161 2012-06-03 20:49:48 ovidiusoft has joined
1162 2012-06-03 20:50:08 <talpan> Permission denied? mhm
1163 2012-06-03 20:50:28 <talpan> check the log, may be there is some more information
1164 2012-06-03 20:50:52 <meLon> /var/log/bit* doesn't exists :\
1165 2012-06-03 20:50:53 <talpan> should be in $HOME/.bitcoin/debug.log
1166 2012-06-03 20:50:56 <meLon> rgr
1167 2012-06-03 20:52:56 <meLon> I dont see it anywhere :\.  Not in my or bitcoin ~/.bitcoin
1168 2012-06-03 20:53:02 <meLon> nor*
1169 2012-06-03 20:53:13 <talpan> is .bitcoin writeable=
1170 2012-06-03 20:53:19 <talpan> ? by the user who runs bitcoind
1171 2012-06-03 20:54:36 <meLon> lmao
1172 2012-06-03 20:54:56 <meLon> <3 talpan I'd untar'd the .bitcoin directory and forgotten to change the permissions of the files
1173 2012-06-03 20:55:07 <talpan> ;) you're welcome
1174 2012-06-03 20:55:35 <bayleef> Should I just upload debug.log? Or something else too?
1175 2012-06-03 20:55:54 Turingi has joined
1176 2012-06-03 20:55:59 <meLon> This is really weird.  I had to change /home/bitcoin/.bitcoin permissions to get it to run, but now it's telling me to put bitcoin.conf in /home/*my* wth
1177 2012-06-03 20:56:22 <talpan> debug.log should be enough
1178 2012-06-03 20:56:30 <luke-jr> bayleef: try git master first
1179 2012-06-03 20:56:33 <talpan> are you using a script to start bitcoind?
1180 2012-06-03 20:56:35 <tcatm_> I wrote a small patch yesterday that adds a -wallet=<file> option. Maybe someone has use for it :) https://github.com/tcatm/bitcoin/commit/3d9db0e416e5538f5442870c05f1cd03f3c072dd
1181 2012-06-03 20:56:53 <luke-jr> tcatm_: that could be dangerous I think
1182 2012-06-03 20:57:05 <bayleef> luke-jr: This is with master, actually
1183 2012-06-03 20:57:25 <luke-jr> bayleef: it's still stuck?
1184 2012-06-03 20:57:30 <tcatm_> luke-jr: Technically it should be safe.
1185 2012-06-03 20:57:31 graingert has joined
1186 2012-06-03 20:57:51 <luke-jr> tcatm_: what if the normal wallet.dat didn't detach (eg, a crash) and you use -wallet with a different one?
1187 2012-06-03 20:59:34 <bayleef> luke-jr: yep, still on block 181808
1188 2012-06-03 21:00:06 <tcatm_> luke-jr: Not sure. I thought bdb might use the filename within its log files?
1189 2012-06-03 21:00:12 <talpan> did you download the latest blockchain and just put it in the bitcoin directory? had this problem once
1190 2012-06-03 21:00:20 <luke-jr> bayleef: OK, run with -detachdb like BlueMatt said, start & shutdown (takes a while), then upload blkindex somewhere
1191 2012-06-03 21:00:24 eoss has quit (Remote host closed the connection)
1192 2012-06-03 21:00:31 <meLon> Okay guys.  sudo su bitcoin - ; bitcoind getinfo works.    bitcoind getinfo as *my* user fails and tells me I need to have a .config file.  How can I work around this?
1193 2012-06-03 21:00:41 eoss has joined
1194 2012-06-03 21:00:43 <talpan> http://eu1.bitcoincharts.com/blockchain/blockchain-2012-06-03.tar
1195 2012-06-03 21:00:53 <luke-jr> meLon: create the config file…
1196 2012-06-03 21:01:04 <luke-jr> talpan: don't do that.
1197 2012-06-03 21:01:09 <talpan> do you have a config file in /home/*user*/.bitcoin/bitcoin.conf?
1198 2012-06-03 21:01:11 <talpan> why not?
1199 2012-06-03 21:01:16 <luke-jr> talpan: it's not secure
1200 2012-06-03 21:01:37 <meLon> No I do not, because I didn't want ot cause complications and stuff and wanted to be 100% sure that the daemon was loading the correct config
1201 2012-06-03 21:01:46 <talpan> in which way? in a way that the source could be wrong or that is causes a crash?
1202 2012-06-03 21:02:05 <luke-jr> talpan: in a way that you could be exploited
1203 2012-06-03 21:02:15 <talpan> meLon: you have to, copy the current bitcoin.conf to the right directory
1204 2012-06-03 21:02:19 <tcatm_> I just verified that bdb is actually using the filename so if wallets are located within $datadir everything should be safe.
1205 2012-06-03 21:02:27 <luke-jr> bitcoind just trusts blk000x is correct, and won't check it unless you manually tell it to
1206 2012-06-03 21:02:57 <luke-jr> tcatm_: common use case I see, is wallet.dat from another directory - will that work? ;)
1207 2012-06-03 21:03:03 <talpan> okay, point taken.
1208 2012-06-03 21:03:37 <meLon> Ahhh, interensting talpan. Sounds like a 'workaround'.  Is that the intended functionality?
1209 2012-06-03 21:03:45 <talpan> just run bitcoind and change the path with -datadir, it should redownload everything
1210 2012-06-03 21:03:50 <talpan> meLon: it is
1211 2012-06-03 21:03:56 <tcatm_> luke-jr: I haven't tried yet and I wouldn't recommend it anyway.
1212 2012-06-03 21:04:23 <talpan> with the latest client the blockchain-download is incredible fast
1213 2012-06-03 21:05:23 <luke-jr> s/fast/slow imo
1214 2012-06-03 21:06:06 paraipan has joined
1215 2012-06-03 21:06:24 <meLon> I am interested in connecting to more than 8 peers.  Is it port 8334 which should be forwarded?  I compiled with USE_UPNP=1, but I don't have UPNP set up correctly atm
1216 2012-06-03 21:06:40 <BlueMatt> luke-jr: bayleef blkindex.dat and blk0001.dat, that is
1217 2012-06-03 21:07:03 <Matt_von_Mises> I'll ask again in case anyone around now knows. For transaction output values, how is the sign represented?
1218 2012-06-03 21:07:10 <luke-jr> BlueMatt: we should write a debug tool that builds blkdat0001.dat from a blkindex.dat :/
1219 2012-06-03 21:07:31 <luke-jr> meLon: 8333
1220 2012-06-03 21:07:40 <luke-jr> Matt_von_Mises: what sign?
1221 2012-06-03 21:07:49 <BlueMatt> tcatm_: btw, when 0.7 comes out, can you stop including blkindex.dat in the blockchain copies (and in the README, put: use -loadblock=blk0001.dat)
1222 2012-06-03 21:08:04 <tcatm_> BlueMatt: Sure.
1223 2012-06-03 21:08:13 <Matt_von_Mises> luke-jr: Output values are signed integers.
1224 2012-06-03 21:08:21 <luke-jr> tcatm_: might make blkindex.dat a separate download, just in case people using 0.4-0.6 want to use them
1225 2012-06-03 21:08:32 meLon has quit (Read error: Connection reset by peer)
1226 2012-06-03 21:08:41 <luke-jr> tcatm_: also, be sure to add detachdb=1 to the config file making those…
1227 2012-06-03 21:08:45 meLon has joined
1228 2012-06-03 21:08:45 meLon has quit (Changing host)
1229 2012-06-03 21:08:45 meLon has joined
1230 2012-06-03 21:08:47 <luke-jr> tcatm_: does it enforce P2SH btw?
1231 2012-06-03 21:08:55 <bayleef> Have another debug log: http://failbox.co.cc/debug-detachdb.log
1232 2012-06-03 21:08:57 <luke-jr> Matt_von_Mises: no, they're not really.
1233 2012-06-03 21:09:08 meLon has quit (Read error: Connection reset by peer)
1234 2012-06-03 21:09:13 <tcatm_> Does stock 0.6.2 enforce P2SH?
1235 2012-06-03 21:09:26 <luke-jr> yes
1236 2012-06-03 21:09:36 <luke-jr> stock 0.6.2 also requires -detachdb already I think
1237 2012-06-03 21:09:45 <BlueMatt> it does
1238 2012-06-03 21:09:48 <Matt_von_Mises> I'm serialising them as unsigned integers at the moment. I need to also consider the sign. As I understand it the only time output values are supposed to be negative is when checking and making transaction signatures...?
1239 2012-06-03 21:09:55 <Matt_von_Mises> When it is -1
1240 2012-06-03 21:10:22 <tcatm_> What does detachdb do?
1241 2012-06-03 21:10:34 drazak has quit (Ping timeout: 252 seconds)
1242 2012-06-03 21:10:44 <luke-jr> Matt_von_Mises: I can't imagine why it would be -1 ever
1243 2012-06-03 21:10:48 <Matt_von_Mises> luke-jr: https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L311 Signed 64 bit integer.
1244 2012-06-03 21:10:59 <luke-jr> tcatm_: without detachdb, blkindex.dat is unusable
1245 2012-06-03 21:11:08 drazak has joined
1246 2012-06-03 21:11:10 <luke-jr> tcatm_: cannot be moved between direcotries that is
1247 2012-06-03 21:11:11 Clipse has quit (Ping timeout: 245 seconds)
1248 2012-06-03 21:11:11 <BlueMatt> tcatm_: if you dont, when you close, its quite possible bdb will depend on including the database folder to open blkindex.dat
1249 2012-06-03 21:11:16 sh00t-first has joined
1250 2012-06-03 21:11:25 meLon has joined
1251 2012-06-03 21:11:54 meLon has quit (Read error: Connection reset by peer)
1252 2012-06-03 21:12:53 <Matt_von_Mises> Apparently it goes through SerReadWrite. I need to figure out what that does...
1253 2012-06-03 21:13:30 <luke-jr> Matt_von_Mises: basically dumps the memory
1254 2012-06-03 21:13:58 meLon has joined
1255 2012-06-03 21:14:09 <Matt_von_Mises> Bitcoin is designed so that it isn't endian neutral? All expected platforms are little-endian?
1256 2012-06-03 21:14:58 <BlueMatt> the satoshi client is
1257 2012-06-03 21:15:05 <Matt_von_Mises> So I take it then that the output values are in twos compliment, little endian...
1258 2012-06-03 21:15:22 <BlueMatt> stored numbers are, yea
1259 2012-06-03 21:15:25 <Matt_von_Mises> I'm not that aware of how integers are stored in memory
1260 2012-06-03 21:15:31 <Matt_von_Mises> BLueMatt: OK thanks.
1261 2012-06-03 21:15:44 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
1262 2012-06-03 21:15:49 <BlueMatt> not just ints, any non-floating numbers, but...yea
1263 2012-06-03 21:16:07 <meLon> Is there a way for me to test my port forwarding?  Anybody want to connect to meh?
1264 2012-06-03 21:16:10 <BlueMatt> but in memory is whatever gcc decides, though uint256 will break (I think) as well as hashing, etc
1265 2012-06-03 21:16:39 <BlueMatt> meLon: http://portforward.com/help/portcheck.htm
1266 2012-06-03 21:16:46 <BlueMatt> oh, nvm thats shit
1267 2012-06-03 21:16:52 <meLon> :P
1268 2012-06-03 21:16:58 <BlueMatt> http://www.yougetsignal.com/tools/open-ports/
1269 2012-06-03 21:16:59 <BlueMatt> there
1270 2012-06-03 21:17:07 <meLon> It's all good. Maybe I should just compile in more connections :D
1271 2012-06-03 21:17:17 <BlueMatt> dont!
1272 2012-06-03 21:17:38 <meLon> >_< Okay okay, but I'm sure you have a good reason?
1273 2012-06-03 21:17:48 mmoya has joined
1274 2012-06-03 21:17:58 <meLon> "connections" : 11 <3
1275 2012-06-03 21:18:00 <BlueMatt> more connections doesnt help you (unless you are mining, but then only a tiny, unmeasurable bit), more outgoing connections starves the network for open nodes to connect to
1276 2012-06-03 21:18:16 <BlueMatt> opening your port gives other nodes on the network more to connect to
1277 2012-06-03 21:18:50 <meLon> Rgr.  So you only want open nodes having more than 8 connections.  Sounds good.  I just want to get through this block download as well as be able to help others in the future.  I have good connection and want to make sure I'm sharing :D
1278 2012-06-03 21:18:51 <Matt_von_Mises> BlueMatt: Can you force GCC into a particular endian? Of-course that would result in major efficiency problems for endianness that doesn't work well with the CPU.
1279 2012-06-03 21:19:02 <BlueMatt> Matt_von_Mises: gcc will use whatever is native on your machine
1280 2012-06-03 21:19:15 <BlueMatt> s/your machine/the machine you tell gcc to compile for (default, what your machine is)
1281 2012-06-03 21:19:34 <BlueMatt> meLon: and the network thanks you ;)
1282 2012-06-03 21:19:56 <luke-jr> meLon: connections aren't useful. listening nodes are.
1283 2012-06-03 21:19:58 sh00t-first has quit (Quit: Page closed)
1284 2012-06-03 21:20:36 * luke-jr wonders if fixing READDATA and WRITEDATA is enough to make Bitcoind portage
1285 2012-06-03 21:20:38 <luke-jr> portable*
1286 2012-06-03 21:20:39 <BlueMatt> meLon: note that block download isnt bandwidth limited except for the early parts, but still
1287 2012-06-03 21:20:58 <BlueMatt> luke-jr: doubt it...sha256?
1288 2012-06-03 21:20:59 <Matt_von_Mises> Basically bitcoin works with x86 which obviously uses little endian. My library should be platform independent so I definitely need to maintain the integer conversion code.
1289 2012-06-03 21:21:15 <luke-jr> BlueMatt: SHA256 is always big endian period.
1290 2012-06-03 21:21:25 <BlueMatt> mmm...
1291 2012-06-03 21:21:45 <luke-jr> Matt_von_Mises: C has it
1292 2012-06-03 21:21:49 <Matt_von_Mises> luke-jr: SHA256 isn't a number? What do you mean by big endian?
1293 2012-06-03 21:21:58 <luke-jr> Matt_von_Mises: man endian
1294 2012-06-03 21:22:14 <luke-jr> Matt_von_Mises: SHA256 always interprets its input as big endian
1295 2012-06-03 21:22:24 <luke-jr> SHA256's algorithm works on 32-bit integers, not characters
1296 2012-06-03 21:22:27 <Matt_von_Mises> Oh, interprets
1297 2012-06-03 21:22:33 <Matt_von_Mises> I thought you mean the output
1298 2012-06-03 21:22:43 <luke-jr> Matt_von_Mises: just use le32toh all over your code ;)
1299 2012-06-03 21:23:06 <luke-jr> or le64toh where appropriate
1300 2012-06-03 21:23:19 <Matt_von_Mises> luke-jr: The typical way is to use bitshifts right? Not hard to just implement that which is what I've already done.
1301 2012-06-03 21:23:26 <luke-jr> Matt_von_Mises: … no
1302 2012-06-03 21:24:07 <Matt_von_Mises> No?
1303 2012-06-03 21:27:14 <Matt_von_Mises> THis is the way I'm doing it: https://github.com/MatthewLM/cbitcoin/blob/master/cbitcoin/src/structures/CBObject/CBByteArray/CBByteArray.c#L205 Simple enough.
1304 2012-06-03 21:28:00 TD has joined
1305 2012-06-03 21:31:11 rdponticelli has joined
1306 2012-06-03 21:31:29 dinox has quit (Ping timeout: 244 seconds)
1307 2012-06-03 21:32:10 <Matt_von_Mises> So if I read the output values as unsigned integers I could just use 0xFFFFFFFFFFFFFFFF for minus one. No need to add additional conversion for the signed integers. I don't even know why the output values are signed integers.
1308 2012-06-03 21:32:42 da2ce7 has quit (Read error: Connection reset by peer)
1309 2012-06-03 21:33:50 Raziel_ has joined
1310 2012-06-03 21:33:58 da2ce7 has joined
1311 2012-06-03 21:34:25 <bayleef> Ah sorry, missed some messages directed toward me... You want the entire 2gb blockchain?
1312 2012-06-03 21:34:40 Sh00tF1rst has joined
1313 2012-06-03 21:36:53 mxmxmx has quit (Remote host closed the connection)
1314 2012-06-03 21:37:25 <BlueMatt> bayleef: yea...
1315 2012-06-03 21:37:52 <Matt_von_Mises> Oh another question, does SIGHASH_SINGLE copy the VarInts for the outputs with empty scripts or are they removed along with the scripts?
1316 2012-06-03 21:37:55 RazielZ has quit (Ping timeout: 265 seconds)
1317 2012-06-03 21:38:02 wladston1 has quit (Quit: Leaving.)
1318 2012-06-03 21:38:23 <Matt_von_Mises> Tried to figure that one out too with little success.
1319 2012-06-03 21:41:34 <sipa> bayleef: have you already started the client with -detachdb ?
1320 2012-06-03 21:43:32 <bayleef> sipa: Yeah, started and stopped
1321 2012-06-03 21:45:23 <sipa> ok, good
1322 2012-06-03 21:45:40 <sipa> are you able to upload the blockchain database files somewhere?
1323 2012-06-03 21:46:41 <bayleef> hardcore archiving action, aw yeah
1324 2012-06-03 21:47:49 <bayleef> should be able to upload to failbox, but it'll take a while...
1325 2012-06-03 21:48:41 rdponticelli has quit (Ping timeout: 245 seconds)
1326 2012-06-03 21:49:35 PK has quit ()
1327 2012-06-03 21:52:32 <meLon> Thanks again guys for helping me get bitcoind running <33
1328 2012-06-03 21:53:53 Vitas has joined
1329 2012-06-03 21:59:50 <sipa> luke-jr: small warning, the dump of the database file is not atomic; if you happen to interrupt it during its dump, you may end up with no database left
1330 2012-06-03 22:00:09 <sipa> luke-jr: also, i've seen occasional unexpected quits since recent changes
1331 2012-06-03 22:00:30 <luke-jr> sipa: what if I run two instances? <.<
1332 2012-06-03 22:00:47 <sipa> don't do it in the same directory
1333 2012-06-03 22:01:36 ovidiusoft has quit (Ping timeout: 265 seconds)
1334 2012-06-03 22:01:47 <sipa> maybe some synchronizing system, or a shared-memory database system can be constructed some day
1335 2012-06-03 22:09:21 <luke-jr> …
1336 2012-06-03 22:09:32 <luke-jr> please tell me bitcoin doesn't use x86 floats in the protocol
1337 2012-06-03 22:09:37 <luke-jr> why does it serialize them? <.<
1338 2012-06-03 22:09:42 <sipa> where?
1339 2012-06-03 22:09:59 <bayleef> BTW can y'all open 7z archives? I was able to compress it into 1.2g
1340 2012-06-03 22:10:07 <sipa> bayleef: sure
1341 2012-06-03 22:10:42 <sipa> luke-jr: i don't know about any place in the protocol where floats are used?
1342 2012-06-03 22:10:58 <luke-jr> sipa: just noticing ::Serialize supports it with WRITEDATA
1343 2012-06-03 22:11:05 <BlueMatt> I hope there arent any places in the protocol floats are used...
1344 2012-06-03 22:11:20 <sipa> well, serialize is used for more than just the netzork protocol
1345 2012-06-03 22:11:21 <luke-jr> BlueMatt: what THAT justify a hardfork IYO? :P
1346 2012-06-03 22:11:48 <BlueMatt> luke-jr: ...
1347 2012-06-03 22:12:01 <luke-jr> :p
1348 2012-06-03 22:12:21 <BlueMatt> maybe Im too anti-hardfork, but I dont think its worth it unless there is a serious issue, not an optimization
1349 2012-06-03 22:12:37 <sipa> there is no issue
1350 2012-06-03 22:13:22 shurnormal has quit (Quit: http://driedleaves.no-ip.org)
1351 2012-06-03 22:17:43 _Fireball has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D)
1352 2012-06-03 22:26:16 sirk390 has quit (Quit: Leaving.)
1353 2012-06-03 22:26:33 copumpkin has quit (Quit: Computer has gone to sleep.)
1354 2012-06-03 22:32:31 <luke-jr> fixing block withholding is an issue, not an optimization
1355 2012-06-03 22:35:15 meLon has quit (Ping timeout: 240 seconds)
1356 2012-06-03 22:35:46 <BlueMatt> you can argue its an issue or an optimization, I dont care, I dont think its a /major/ issue
1357 2012-06-03 22:36:06 <sipa> what are we discussing?
1358 2012-06-03 22:36:54 saieko has quit (Ping timeout: 245 seconds)
1359 2012-06-03 22:38:40 <BlueMatt> hardforking to fix block withholding from pools
1360 2012-06-03 22:39:08 <BlueMatt> anyone know of an actually good software to automate make dispatching to multiple machines?
1361 2012-06-03 22:39:12 <BlueMatt> gxpc sucks...
1362 2012-06-03 22:39:43 slush has joined
1363 2012-06-03 22:41:28 talpan has quit (Remote host closed the connection)
1364 2012-06-03 22:42:01 rdponticelli has joined
1365 2012-06-03 22:42:20 <BlueMatt> even still, compiling bitcoin across two machines is awesome
1366 2012-06-03 22:42:21 sacredchao has joined
1367 2012-06-03 22:42:35 Joric has quit (Read error: Connection reset by peer)
1368 2012-06-03 22:42:37 Joric_ has joined
1369 2012-06-03 22:42:37 Joric_ has quit (Changing host)
1370 2012-06-03 22:42:37 Joric_ has joined
1371 2012-06-03 22:43:05 copumpkin has joined
1372 2012-06-03 22:44:37 <bayleef> about 2 hours left on that upload
1373 2012-06-03 22:44:50 Hasbro has quit (Ping timeout: 260 seconds)
1374 2012-06-03 22:45:13 <sipa> i'll be off by then, but i suppose it'll stay there for a a while?
1375 2012-06-03 22:45:28 <sipa> if not, ask gmaxwell or someone to fetch it
1376 2012-06-03 22:46:14 <BlueMatt> Ill be around
1377 2012-06-03 22:46:28 TD has quit (Quit: TD)
1378 2012-06-03 22:46:42 <bayleef> Yay :D
1379 2012-06-03 22:46:51 Joric_ has quit (Client Quit)
1380 2012-06-03 22:46:58 da2ce7 has quit (Read error: Connection reset by peer)
1381 2012-06-03 22:47:33 <GTRsdk> BlueMatt: was the compilation process successful?
1382 2012-06-03 22:48:16 da2ce7 has joined
1383 2012-06-03 22:48:33 <BlueMatt> GTRsdk: yea, it runs np, but for the life of me I cant figure out how to make gxpc run multiple processes per core...
1384 2012-06-03 22:48:46 <sipa> why do you want that.
1385 2012-06-03 22:49:07 <bayleef> I'm curious what this will accomplish, though. Could my blockchain be corrupt?
1386 2012-06-03 22:49:08 <sipa> the normal advice is n+1 threads if you have n (real) cores
1387 2012-06-03 22:49:27 <BlueMatt> because when I look at top, I average missing a core while the scheduler dicks around
1388 2012-06-03 22:49:34 <sipa> bayleef: possibly, but it still shouldn't get stuck
1389 2012-06-03 22:49:42 <BlueMatt> and I end up with 3 ccs on one core for a second...
1390 2012-06-03 22:50:18 * GTRsdk can't get the latest git commit to compile for some reason
1391 2012-06-03 22:50:55 <sipa> GTRsdk: what error?
1392 2012-06-03 22:51:05 saieko has joined
1393 2012-06-03 22:51:09 <BlueMatt> jenkins is happy...
1394 2012-06-03 22:52:09 erle- has quit (Quit: erle-)
1395 2012-06-03 22:53:43 <BlueMatt> bayleef: its clearly corrupt, but how or why we dont know, and its a whole lot easier to take a look manually if we have the chain, instead of trying to parse what is going on from debug.log
1396 2012-06-03 22:59:17 <GTRsdk> sipa: g++: internal compiler error: Killed (program cc1plus)
1397 2012-06-03 23:00:18 <sipa> OOM?
1398 2012-06-03 23:01:44 <GTRsdk> OOM == what?
1399 2012-06-03 23:01:53 <BlueMatt> out of memory
1400 2012-06-03 23:02:26 <GTRsdk> doubt it, but I will check
1401 2012-06-03 23:02:58 <GTRsdk> for now... the full output is over at http://pb.lui.li/9bb1329d66a5c3e1
1402 2012-06-03 23:04:38 <BlueMatt> even if its not oom, it still looks like a gcc bug
1403 2012-06-03 23:04:56 <BlueMatt> or drive corruption, etc
1404 2012-06-03 23:05:00 <BlueMatt> something weird
1405 2012-06-03 23:06:55 Matt_von_Mises has left ()
1406 2012-06-03 23:12:03 Prattler has joined
1407 2012-06-03 23:18:33 ThomasV has joined
1408 2012-06-03 23:18:37 Joric has joined
1409 2012-06-03 23:18:37 Joric has quit (Changing host)
1410 2012-06-03 23:18:37 Joric has joined
1411 2012-06-03 23:19:55 egecko has joined
1412 2012-06-03 23:22:55 <gribble> New news from bitcoinrss: dooglus opened pull request 1415 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1415>
1413 2012-06-03 23:30:08 meLon has joined
1414 2012-06-03 23:30:14 saieko has quit (Ping timeout: 245 seconds)
1415 2012-06-03 23:31:01 mmoya has quit (Ping timeout: 265 seconds)
1416 2012-06-03 23:36:01 ThomasV has quit (Ping timeout: 244 seconds)
1417 2012-06-03 23:36:11 saieko has joined
1418 2012-06-03 23:37:31 Raziel_ has quit (Quit: Leaving)
1419 2012-06-03 23:40:09 drazak has quit (Ping timeout: 244 seconds)
1420 2012-06-03 23:41:20 drazak has joined
1421 2012-06-03 23:45:16 JZavala has joined
1422 2012-06-03 23:51:31 eoss has quit (Remote host closed the connection)
1423 2012-06-03 23:59:09 Turingi has quit (Read error: Connection reset by peer)