1 2013-07-22 00:06:24 ericmuyser has joined
   2 2013-07-22 00:16:06 slush has quit (Ping timeout: 240 seconds)
   3 2013-07-22 00:19:21 gjj_ has joined
   4 2013-07-22 00:22:17 gjj has quit (Read error: No route to host)
   5 2013-07-22 00:22:43 gjj has joined
   6 2013-07-22 00:25:31 macboz has joined
   7 2013-07-22 00:26:11 iwilcox has quit (Ping timeout: 264 seconds)
   8 2013-07-22 00:26:19 gjj_ has quit (Ping timeout: 276 seconds)
   9 2013-07-22 00:32:26 one_zero has joined
  10 2013-07-22 00:39:03 Zoop95 has quit ()
  11 2013-07-22 00:39:21 Zoop_ has joined
  12 2013-07-22 00:40:36 skeledrew1 has quit (Ping timeout: 245 seconds)
  13 2013-07-22 00:46:17 AusBitBank__ has quit (Quit: later)
  14 2013-07-22 00:50:09 skeledrew has joined
  15 2013-07-22 00:55:50 melvster_ has quit (Ping timeout: 246 seconds)
  16 2013-07-22 01:03:31 fraiska has joined
  17 2013-07-22 01:03:31 theo__ has joined
  18 2013-07-22 01:03:36 Grishnakh_ has quit (Read error: Connection reset by peer)
  19 2013-07-22 01:03:36 CodeShark has quit (Remote host closed the connection)
  20 2013-07-22 01:05:30 grau has joined
  21 2013-07-22 01:06:37 CodeShark has joined
  22 2013-07-22 01:06:41 theo` has quit (Ping timeout: 246 seconds)
  23 2013-07-22 01:06:57 CodeShark has quit (Remote host closed the connection)
  24 2013-07-22 01:09:36 grau has quit (Ping timeout: 240 seconds)
  25 2013-07-22 01:13:02 viperhr has joined
  26 2013-07-22 01:15:05 paybitcoin1 has quit (Read error: Connection reset by peer)
  27 2013-07-22 01:16:07 paybitcoin has joined
  28 2013-07-22 01:17:18 Tabaza has quit ()
  29 2013-07-22 01:18:07 B0g4r7 has joined
  30 2013-07-22 01:24:20 h2odysee_ has quit (Ping timeout: 260 seconds)
  31 2013-07-22 01:26:35 fluxbox_ has joined
  32 2013-07-22 01:30:23 fluxbox___ has quit (Ping timeout: 264 seconds)
  33 2013-07-22 01:32:05 saintcajetan has joined
  34 2013-07-22 01:40:16 cads has joined
  35 2013-07-22 01:48:42 reazies has joined
  36 2013-07-22 01:52:35 reazies has quit (Client Quit)
  37 2013-07-22 01:54:40 zer0def has quit (Ping timeout: 260 seconds)
  38 2013-07-22 01:54:46 realz has joined
  39 2013-07-22 01:55:09 realz is now known as Guest75564
  40 2013-07-22 01:55:16 toffoo has joined
  41 2013-07-22 01:57:08 Guest75564 has left ()
  42 2013-07-22 02:05:53 michagogo has joined
  43 2013-07-22 02:05:53 michagogo has quit (Changing host)
  44 2013-07-22 02:05:53 michagogo has joined
  45 2013-07-22 02:22:10 fluxbox_ has quit (Ping timeout: 248 seconds)
  46 2013-07-22 02:25:08 fluxbox has joined
  47 2013-07-22 02:25:24 fluxbox has quit (Client Quit)
  48 2013-07-22 02:29:24 c0rw1n has quit (Remote host closed the connection)
  49 2013-07-22 02:30:35 Subo1978 has joined
  50 2013-07-22 02:32:09 Gnaf has quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
  51 2013-07-22 02:32:32 Gnaf has joined
  52 2013-07-22 02:34:01 Applicat_ has joined
  53 2013-07-22 02:34:22 Subo1978_ has quit (Ping timeout: 240 seconds)
  54 2013-07-22 02:37:06 Application has quit (Ping timeout: 240 seconds)
  55 2013-07-22 02:39:00 * Luke-Jr ponders if the warning in LevelDB might be related to the corruption issues
  56 2013-07-22 02:39:15 <Luke-Jr> probably not, if the file is posix_logger.h
  57 2013-07-22 02:39:26 c0rw1n has joined
  58 2013-07-22 02:51:26 ThomasV has joined
  59 2013-07-22 02:54:42 justusranvier has quit (Ping timeout: 240 seconds)
  60 2013-07-22 02:55:07 <JyZyXEL> just how unsafe it is to accept 0/unconfirmed as a payment?
  61 2013-07-22 02:55:21 <gmaxwell> as payment for what?
  62 2013-07-22 02:55:28 <JyZyXEL> for goods and services
  63 2013-07-22 02:55:36 <gmaxwell> the details matter.
  64 2013-07-22 02:56:07 <JyZyXEL> well i heard in this podcast that people on some festival were accepting bitcoin payments with 0 confirmations
  65 2013-07-22 02:56:08 <gmaxwell> it's pretty easy to reverse an unconfirmed payment. If you're operating in a context where thats bad, then thats bad.
  66 2013-07-22 02:56:51 <gmaxwell> JyZyXEL: presumably, if they even understood the risks at all, they just planned on eating whatever losses they had.
  67 2013-07-22 02:56:57 <gmaxwell> Sometimes thats perfectly reasonable.
  68 2013-07-22 02:57:17 <gmaxwell> Often if the txn is reversed you can abort the transaction, and then thats fine too.
  69 2013-07-22 02:57:35 <gwillen> JyZyXEL: in general, it's totally unsafe and you shouldn't do it
  70 2013-07-22 02:57:36 <JyZyXEL> i guess they were selling food items and such and couldn't really have people waiting there for the confirmations or something :p
  71 2013-07-22 02:57:55 <gwillen> JyZyXEL: but like, if you're selling someone access to a website, it doesn't matter, because if they reverse the payment you just cut off their access
  72 2013-07-22 02:58:05 <gmaxwell> Or you know you you were transacting with and "wtf, dude, pay up or I call your mom"
  73 2013-07-22 02:58:08 <gwillen> JyZyXEL: and if you're selling a doughnut, it's probably so cheap that it doesn't amtter
  74 2013-07-22 02:58:51 <gmaxwell> but in cases where you can't eat it, and where you can't abort, and where you can't hunt them down ... and especially if one person could screw you over and over again (e.g. with a bot) then you shouldn't be accepting them.
  75 2013-07-22 02:59:21 <gmaxwell> (you probably shouldn't be accepting just 1 in that case either)
  76 2013-07-22 02:59:42 <gmaxwell> (esp if the attack could be automated)
  77 2013-07-22 03:00:00 <gwillen> in general accepting 0 is not a good idea unless you have a detailed understanding of the specific ways that low-confirm bitcoin transactions can be reversed, OR the transaction is zero-risk for you even if it does get reversed
  78 2013-07-22 03:00:20 justusranvier has joined
  79 2013-07-22 03:00:29 <JyZyXEL> i'd like to know more how does one reverse it?
  80 2013-07-22 03:00:39 <gmaxwell> as often as they want.
  81 2013-07-22 03:01:06 <gmaxwell> The question you're asking about is not a random failure. It's not something that has a rate like a failing lightbulb.
  82 2013-07-22 03:01:25 <gwillen> gmaxwell: not how often, how
  83 2013-07-22 03:01:51 <gwillen> JyZyXEL: with zero confirms, they can do things like sending two conflicting transactions to different nodes in the network
  84 2013-07-22 03:01:54 ForceMajeure_ has quit (Remote host closed the connection)
  85 2013-07-22 03:02:00 <gwillen> and only one of those can succeed
  86 2013-07-22 03:02:14 <gwillen> so if they can get you to see one, and get the other one to succeed, then they can make you think they're paying you, but really pay themselves
  87 2013-07-22 03:02:35 <gmaxwell> gwillen: thanks for the reading comprehension help. :P
  88 2013-07-22 03:02:39 <gwillen> np :-)
  89 2013-07-22 03:03:14 <gmaxwell> Yes, the simplest way is to simply produce two payments and ~concurrently announce.
  90 2013-07-22 03:03:33 <gmaxwell> blockchain.info even has a handy integrated tool for doing this attack.
  91 2013-07-22 03:03:37 yubrew has joined
  92 2013-07-22 03:03:38 <michagogo> JyZyXEL: This is especially bad if they can find and connect to your node.
  93 2013-07-22 03:04:39 <gmaxwell> michagogo: you can actually use doublespend propagations to find the relevant nodes if you can pay a couple times.
  94 2013-07-22 03:04:52 <gmaxwell> michagogo: but really doing that isn't supremely important.
  95 2013-07-22 03:05:06 eoss has joined
  96 2013-07-22 03:05:11 yubrew_ has quit (Ping timeout: 245 seconds)
  97 2013-07-22 03:05:43 <gmaxwell> accepting unconfirmed also exposes you to things like someone paying you with a very low priority txn that will fall out of mempools before getting mined. Makes it pretty easy to reliably replace with one that has a fee.
  98 2013-07-22 03:05:59 <michagogo> gmaxwell: Right, but it's still a way to improve the success rates (i.e. the merchant seeing your transaction and not the conflicting one)
  99 2013-07-22 03:10:31 skeledrew has quit (Read error: Connection reset by peer)
 100 2013-07-22 03:11:02 MobiusL has quit (Ping timeout: 240 seconds)
 101 2013-07-22 03:11:09 malaimo has quit (Ping timeout: 248 seconds)
 102 2013-07-22 03:11:22 <JyZyXEL> pay the merchant with normal fee and then make another competing transaction with higher fee?
 103 2013-07-22 03:12:35 <JyZyXEL> since miners cannot include both transactions in to a block they would probably prefer to include the one with higher fee?
 104 2013-07-22 03:12:49 <gwillen> JyZyXEL: right now in general it doesn't work quite that way
 105 2013-07-22 03:13:07 <gwillen> JyZyXEL: but the same general idea, that you get the merchant to see one transaction, and the miner to mine a different one
 106 2013-07-22 03:13:19 malaimo has joined
 107 2013-07-22 03:13:24 stamit1 has joined
 108 2013-07-22 03:14:47 <JyZyXEL> if i was a merchant i would have my wallet connected to very popular nodes like blockchain.info or something like that
 109 2013-07-22 03:19:35 Application has joined
 110 2013-07-22 03:21:38 kreal has joined
 111 2013-07-22 03:22:57 michagogo has left ()
 112 2013-07-22 03:23:06 michagogo has joined
 113 2013-07-22 03:23:09 <michagogo> oops
 114 2013-07-22 03:23:30 Applicat_ has quit (Ping timeout: 248 seconds)
 115 2013-07-22 03:25:33 ralphtheninja has quit (Ping timeout: 248 seconds)
 116 2013-07-22 03:29:43 <gwillen> JyZyXEL: yes, that's an important step to protect yourself as a merchant
 117 2013-07-22 03:29:53 <gwillen> JyZyXEL: really you want to be connected to all the major mining pools
 118 2013-07-22 03:30:18 <gwillen> JyZyXEL: if you _receive_ the same transaction from each of the major mining pools' nodes, you have a good chance that a conflicting one will not be mined
 119 2013-07-22 03:30:33 <gwillen> but I am not an expert so you shouldn't stake any money on my claim; there are more subtleties, undoubtedly
 120 2013-07-22 03:31:10 <gmaxwell> gwillen: there is basically no software to do what you're suggesting, and it's not clear how worthwhile it is.
 121 2013-07-22 03:31:27 <JyZyXEL> and if you receive two transactions for the same coins, then something fishy is going on? :p
 122 2013-07-22 03:31:27 kreal has quit ()
 123 2013-07-22 03:31:46 <gmaxwell> The problem is that getting a txn from a mining pool is no guarentee that they're mining it (any mining pool you could connect to runs many nodes, and the important ones aren't exposed)
 124 2013-07-22 03:32:02 stamit1 has quit (Remote host closed the connection)
 125 2013-07-22 03:32:03 <gmaxwell> certantly being well connected is helpful though.
 126 2013-07-22 03:32:29 <gwillen> JyZyXEL: listen to gmaxwell rather than me
 127 2013-07-22 03:32:33 <gwillen> he knows of what he speaks
 128 2013-07-22 03:32:38 <MC1984> does going out of your way to peer with "major mining pools" really grant you useful extra protection
 129 2013-07-22 03:33:23 <gmaxwell> MC1984: as I was saying, probably not. Being well connected is good, otoh: well connected sometimes blinds you to conflicts, and no widely used software warns you about them either, AFAIK.
 130 2013-07-22 03:33:41 <MC1984> simply well connected is fine
 131 2013-07-22 03:33:47 <MC1984> a given even
 132 2013-07-22 03:34:56 <MC1984> i want to be able to listen on and inject txn thru the jankiest couple of nodes in the netwok and not have it be a problem
 133 2013-07-22 03:35:28 <MC1984> eg decently amorphous fuzzball of a network
 134 2013-07-22 03:37:05 <JyZyXEL> so if you send two competing transactions (spending the same coins) to very well connected nodes, which ever transaction gets the first confirmation is likely to be the one that wins?
 135 2013-07-22 03:37:33 MobiusL has joined
 136 2013-07-22 03:37:42 <gwillen> JyZyXEL: yes, and one-confirmation is much much safer than zero
 137 2013-07-22 03:37:50 <gwillen> (but still significantly less safe than two)
 138 2013-07-22 03:38:15 <gmaxwell> gwillen: well maybe safer! depends on the attack being done. But yes, in the case where two get announced the first to get a confirm is likely the survivor.
 139 2013-07-22 03:38:26 <JyZyXEL> would the miners who know about the one confirmation even care about the other transaction anymore?
 140 2013-07-22 03:38:36 <gwillen> gmaxwell: well, safer in that it doesn't take a lot in the way of resources or help to attack zero-confirm
 141 2013-07-22 03:38:40 <gmaxwell> JyZyXEL: because of this awesome thing called latency.
 142 2013-07-22 03:38:47 <gwillen> whereas to successfully attack one-confirm, you need _some_ mining power
 143 2013-07-22 03:38:51 <gwillen> for zero-confirm you really don't need any
 144 2013-07-22 03:38:54 <gmaxwell> gwillen: no, not so.
 145 2013-07-22 03:38:57 <gwillen> no?
 146 2013-07-22 03:39:25 <gmaxwell> Say I broadcast two transactions. Miner A gets txn A, miner B gets txn B first.
 147 2013-07-22 03:39:45 <gmaxwell> now A produces a block, but 4 seconds later B also produces a block.
 148 2013-07-22 03:39:58 <gmaxwell> You see A's confirm.. you now have 1 confirmed.
 149 2013-07-22 03:40:01 <gwillen> okay, but now we're talking about attacks that can only be executed with a great deal of luck or patience
 150 2013-07-22 03:40:12 <gmaxwell> gwillen: this sequence happens a couple times a day naturally.
 151 2013-07-22 03:40:15 <gwillen> whereas zero-confirm attacks do not require nearly as much of either
 152 2013-07-22 03:40:16 <gwillen> hm, *nods*
 153 2013-07-22 03:40:36 <gmaxwell> gwillen: so if you constantly send two transactions you'll hit 1 and get a reversal every once in a while without any hashpower.
 154 2013-07-22 03:40:36 <gwillen> well, but it's not enough for that sequence to happen
 155 2013-07-22 03:40:42 <gwillen> you need that sequence to happen AND you need B's later block to win
 156 2013-07-22 03:41:02 robocoin has quit (Ping timeout: 246 seconds)
 157 2013-07-22 03:41:02 <gwillen> anyway.
 158 2013-07-22 03:41:11 <gmaxwell> Yes, and then B gets another block or C decided to extend B because it heard B first. (not at all unlikely with a 4 second span)
 159 2013-07-22 03:41:41 <gmaxwell> gwillen: the exact rate depends on the network, it's not hard to demonstrate though.
 160 2013-07-22 03:41:45 * gwillen nods
 161 2013-07-22 03:41:47 macboz has quit (Quit: This computer has gone to sleep)
 162 2013-07-22 03:42:35 eoss has quit (Remote host closed the connection)
 163 2013-07-22 03:42:38 <gmaxwell> if you instead assume the attacker hash access to hashpower (e.g. via something like one of those mining resale services) then thats a different set of risks.
 164 2013-07-22 03:43:01 jchp has joined
 165 2013-07-22 03:43:17 <MC1984> how much does it really cost to pull a finney now
 166 2013-07-22 03:43:20 c0rw1n has quit (Remote host closed the connection)
 167 2013-07-22 03:44:25 macboz has joined
 168 2013-07-22 03:44:32 <gmaxwell> I actually think all those hashpower sale services are currently out of business again.
 169 2013-07-22 03:44:38 fanquake has left ()
 170 2013-07-22 03:44:46 ThomasV has quit (Ping timeout: 264 seconds)
 171 2013-07-22 03:45:01 <MC1984> lol
 172 2013-07-22 03:45:39 <JyZyXEL> one thing that i like is how the transactions from an orphan block get automatically re-added to the pool of queued transactions so that lessens the risk of having an accidental reversal of payment
 173 2013-07-22 03:46:02 <gmaxwell> yes, though they won't bump already queued transactions.
 174 2013-07-22 03:46:29 <MC1984> oh github has changed marginally
 175 2013-07-22 03:46:59 fanquake has joined
 176 2013-07-22 03:47:19 <MC1984> merged #2670 qt: allow user to choose data directory
 177 2013-07-22 03:47:20 <MC1984> nice
 178 2013-07-22 03:51:46 <gmaxwell> gwillen: in any case, thinking about low confirm security is hard.
 179 2013-07-22 03:51:52 * gwillen nods
 180 2013-07-22 03:51:53 <gwillen> agreed
 181 2013-07-22 03:52:49 <gmaxwell> it's especially a problem for things unattended things that allow depost and withdraw.
 182 2013-07-22 03:53:14 <gmaxwell> lots of otherwise infesable attacks— because they have low success rates— work fine if you can try over and over again.
 183 2013-07-22 03:54:26 TheSeven has quit (Disconnected by services)
 184 2013-07-22 03:54:38 [7] has joined
 185 2013-07-22 04:04:35 Tabaza has joined
 186 2013-07-22 04:04:43 <Tabaza> where are the developers?
 187 2013-07-22 04:04:46 <Tabaza> i mean
 188 2013-07-22 04:04:48 <Tabaza> the serious ones?
 189 2013-07-22 04:05:09 skeledrew has joined
 190 2013-07-22 04:05:17 <michagogo> Tabaza: In here, many of them
 191 2013-07-22 04:05:30 <michagogo> Why?
 192 2013-07-22 04:05:56 <Tabaza> i want to develop bitcoin trading/exchange system
 193 2013-07-22 04:06:02 <Tabaza> to be secured and reliable
 194 2013-07-22 04:06:11 gritball_ has joined
 195 2013-07-22 04:06:12 <Tabaza> can y ou highlight some companies who can do the task?
 196 2013-07-22 04:07:07 jchp_ has joined
 197 2013-07-22 04:07:42 imton has quit (Quit: imton)
 198 2013-07-22 04:07:46 [7] has quit (Disconnected by services)
 199 2013-07-22 04:07:55 TheSeven has joined
 200 2013-07-22 04:08:17 ericmuys_ has joined
 201 2013-07-22 04:09:56 meLon has quit (Disconnected by services)
 202 2013-07-22 04:09:58 meLon_ has joined
 203 2013-07-22 04:11:29 MCM-Mike_ has joined
 204 2013-07-22 04:12:11 sserrano_ has joined
 205 2013-07-22 04:12:29 jaromil_ has joined
 206 2013-07-22 04:13:08 <Tabaza> michagogo?
 207 2013-07-22 04:14:01 agnostic_ has joined
 208 2013-07-22 04:14:54 <TheLordOfTime> Tabaza:  patience.  it is a virtue.
 209 2013-07-22 04:15:03 <TheLordOfTime> michagogo could also be slightly busy so... :P
 210 2013-07-22 04:16:25 stamit1 has joined
 211 2013-07-22 04:16:33 <Tabaza> yeah
 212 2013-07-22 04:16:40 stamit1 has left ()
 213 2013-07-22 04:16:44 <Tabaza> everyday pass without my system up
 214 2013-07-22 04:16:46 realz has joined
 215 2013-07-22 04:16:48 <Tabaza> i am losing money :P
 216 2013-07-22 04:16:54 <TheLordOfTime> oh geez, it's stamit again
 217 2013-07-22 04:16:55 <TheLordOfTime> :/
 218 2013-07-22 04:17:07 platoscave has quit (Ping timeout: 264 seconds)
 219 2013-07-22 04:17:16 realz is now known as Guest98799
 220 2013-07-22 04:17:21 <TheLordOfTime> this is the only place he can really join to though... and even then he can't do anything last i checked
 221 2013-07-22 04:17:26 <TheLordOfTime> yep he can't.
 222 2013-07-22 04:17:42 stamit1 has joined
 223 2013-07-22 04:17:44 cads has joined
 224 2013-07-22 04:17:46 stamit1 has left ()
 225 2013-07-22 04:18:16 Guest98799 has left ()
 226 2013-07-22 04:18:42 sserrano_ is now known as sserrano44
 227 2013-07-22 04:22:24 platoscave has joined
 228 2013-07-22 04:22:30 platoscave has quit (Max SendQ exceeded)
 229 2013-07-22 04:22:38 xenland has quit (Quit: Konversation terminated!)
 230 2013-07-22 04:23:02 <gjs278> why the hell does freenode disconnect to often jesus
 231 2013-07-22 04:23:18 gjs278 has joined
 232 2013-07-22 04:23:56 platoscave has joined
 233 2013-07-22 04:24:03 platoscave has quit (Max SendQ exceeded)
 234 2013-07-22 04:27:30 platoscave has joined
 235 2013-07-22 04:28:59 serialbandicoot has joined
 236 2013-07-22 04:32:49 Gnaf has quit (Quit: for (i = first; i < size; i += prime) marked[i] = 1;)
 237 2013-07-22 04:33:55 grau has joined
 238 2013-07-22 04:34:01 <TheLordOfTime> gjs278:  no idea.
 239 2013-07-22 04:34:15 <TheLordOfTime> just live with it for a while because it looks like they're doing server maintenance and shuffling
 240 2013-07-22 04:35:41 <gjs278> yeah on reconnect my irc client stopped trying because it somehow connected to a server that didn't have ssl on
 241 2013-07-22 04:38:29 toffoo has joined
 242 2013-07-22 04:39:04 <TheLordOfTime> that was probably the newest server, maybe.
 243 2013-07-22 04:39:12 <TheLordOfTime> but anyways, all looks good now.  :)
 244 2013-07-22 04:46:12 EPiSKiNG- has joined
 245 2013-07-22 04:50:15 RoboHege has quit (Remote host closed the connection)
 246 2013-07-22 04:57:19 Gnaf has joined
 247 2013-07-22 04:59:35 cads has quit (Quit: Leaving)
 248 2013-07-22 04:59:57 cads has joined
 249 2013-07-22 05:02:06 Prattler has quit (Quit: ZNC - http://znc.in)
 250 2013-07-22 05:03:21 rlifchitz has joined
 251 2013-07-22 05:03:21 rlifchitz has quit (Changing host)
 252 2013-07-22 05:03:21 rlifchitz has joined
 253 2013-07-22 05:03:55 michagogo has quit (Quit: goodnight)
 254 2013-07-22 05:09:16 realzies has joined
 255 2013-07-22 05:11:37 platoscave has quit (Ping timeout: 240 seconds)
 256 2013-07-22 05:12:50 macboz has quit (Ping timeout: 248 seconds)
 257 2013-07-22 05:15:01 andyh2 has joined
 258 2013-07-22 05:16:52 alexwaters has joined
 259 2013-07-22 05:16:52 alexwaters has quit (Changing host)
 260 2013-07-22 05:16:52 alexwaters has joined
 261 2013-07-22 05:18:20 platoscave has joined
 262 2013-07-22 05:22:48 copumpkin has quit (Ping timeout: 260 seconds)
 263 2013-07-22 05:23:27 copumpkin has joined
 264 2013-07-22 05:24:06 alexwaters has quit (Remote host closed the connection)
 265 2013-07-22 05:24:42 bonks_ has joined
 266 2013-07-22 05:25:32 alexwaters has joined
 267 2013-07-22 05:26:30 bonks has quit (Disconnected by services)
 268 2013-07-22 05:26:40 bonks_ is now known as bonks
 269 2013-07-22 05:33:21 jeewee has joined
 270 2013-07-22 05:34:04 owowo has quit (Quit: dead)
 271 2013-07-22 05:44:17 RBecker has joined
 272 2013-07-22 05:44:31 alexwaters has quit (Remote host closed the connection)
 273 2013-07-22 05:44:53 macboz has joined
 274 2013-07-22 05:45:25 alexwaters has joined
 275 2013-07-22 05:53:40 <Luke-Jr> sipa: ping
 276 2013-07-22 05:55:46 <Luke-Jr> nm
 277 2013-07-22 05:56:03 alexwaters has quit (Remote host closed the connection)
 278 2013-07-22 05:58:24 Skav has joined
 279 2013-07-22 06:00:43 MobPhone_ has joined
 280 2013-07-22 06:00:45 MobPhone has quit (Ping timeout: 269 seconds)
 281 2013-07-22 06:02:37 h2odysee has joined
 282 2013-07-22 06:02:58 Skav has quit (Ping timeout: 248 seconds)
 283 2013-07-22 06:04:18 CodeName has joined
 284 2013-07-22 06:04:41 <sipa> Luke-Jr: ok?
 285 2013-07-22 06:05:02 <Luke-Jr> sipa: your BIP32 tests are doing some fancy things :p
 286 2013-07-22 06:05:19 <Luke-Jr> and the BIP32 pull doesn't work with your secp branch <.<
 287 2013-07-22 06:05:27 <sipa> i know
 288 2013-07-22 06:05:43 <sipa> i'll rebase once it's merged
 289 2013-07-22 06:06:09 <sipa> is overloading operator() fancy? :p
 290 2013-07-22 06:07:54 <Luke-Jr> sipa: well, basing the next test on the results of the previous
 291 2013-07-22 06:08:38 <Luke-Jr> I had #ifndef'd out the derive-based tests, and missed that their result influenced the next test run
 292 2013-07-22 06:09:24 <sipa> ah, right
 293 2013-07-22 06:16:32 MoALTz has joined
 294 2013-07-22 06:17:50 MoALTz_ has quit (Ping timeout: 246 seconds)
 295 2013-07-22 06:20:27 jeewee has quit (Quit: Leaving.)
 296 2013-07-22 06:27:52 CodeName has quit (Ping timeout: 268 seconds)
 297 2013-07-22 06:35:54 Tabaza has left ()
 298 2013-07-22 06:36:50 iwilcox has joined
 299 2013-07-22 06:47:52 iwilcox_ has joined
 300 2013-07-22 06:48:37 hoolandi1 has joined
 301 2013-07-22 06:51:55 iwilcox has quit (Ping timeout: 264 seconds)
 302 2013-07-22 06:57:46 jeewee has joined
 303 2013-07-22 06:59:22 Eiii has quit ()
 304 2013-07-22 06:59:37 slush has joined
 305 2013-07-22 06:59:58 PrimeStunna has quit (Quit: PrimeStunna)
 306 2013-07-22 07:00:03 melvster_ has joined
 307 2013-07-22 07:04:47 alexwaters has joined
 308 2013-07-22 07:08:41 CodeShark has joined
 309 2013-07-22 07:12:14 alexwaters has quit (Remote host closed the connection)
 310 2013-07-22 07:12:50 macboz has quit (Ping timeout: 248 seconds)
 311 2013-07-22 07:13:17 CodeShar_ has joined
 312 2013-07-22 07:13:22 CodeShark has quit (Ping timeout: 248 seconds)
 313 2013-07-22 07:18:50 iwilcox has joined
 314 2013-07-22 07:19:24 macboz has joined
 315 2013-07-22 07:21:55 iwilcox_ has quit (Ping timeout: 264 seconds)
 316 2013-07-22 07:23:46 xyguy has joined
 317 2013-07-22 07:24:51 RoboTeddy has joined
 318 2013-07-22 07:25:15 zer0def has joined
 319 2013-07-22 07:29:59 agnostic_ has quit (Remote host closed the connection)
 320 2013-07-22 07:36:52 jamesonwa has quit (Remote host closed the connection)
 321 2013-07-22 07:40:38 mappum has quit (Ping timeout: 268 seconds)
 322 2013-07-22 07:51:42 johnsoft has quit (Ping timeout: 248 seconds)
 323 2013-07-22 07:53:09 hoolandi1 has left ()
 324 2013-07-22 07:53:38 paracyst has quit ()
 325 2013-07-22 07:56:14 Prattler has joined
 326 2013-07-22 07:57:58 OPrime has joined
 327 2013-07-22 08:00:22 agnostic98 has joined
 328 2013-07-22 08:06:28 agnostic98 has quit (Read error: Connection reset by peer)
 329 2013-07-22 08:06:33 viperhr has quit (Ping timeout: 256 seconds)
 330 2013-07-22 08:09:12 jeewee has quit (Quit: Leaving.)
 331 2013-07-22 08:13:01 t7 has joined
 332 2013-07-22 08:19:51 wamatt has quit (Quit: wamatt)
 333 2013-07-22 08:20:36 viperhr has joined
 334 2013-07-22 08:21:28 xyguy has quit (Quit: Page closed)
 335 2013-07-22 08:30:05 iwilcox has quit (Read error: Connection reset by peer)
 336 2013-07-22 08:30:55 gjj has quit (Remote host closed the connection)
 337 2013-07-22 08:33:35 iwilcox has joined
 338 2013-07-22 08:33:35 iwilcox has quit (Changing host)
 339 2013-07-22 08:33:35 iwilcox has joined
 340 2013-07-22 08:38:53 enikanorov has quit (Read error: Connection reset by peer)
 341 2013-07-22 08:39:13 enikanorov has joined
 342 2013-07-22 08:43:14 gjj has joined
 343 2013-07-22 08:43:36 gjj has quit (Remote host closed the connection)
 344 2013-07-22 08:44:09 gjj has joined
 345 2013-07-22 08:50:44 epscylonb has left ()
 346 2013-07-22 08:51:46 epscyl has joined
 347 2013-07-22 08:52:11 epscyl has left ()
 348 2013-07-22 08:52:32 epscy has joined
 349 2013-07-22 08:55:37 Diapolo has joined
 350 2013-07-22 08:55:43 Diapolo has left ()
 351 2013-07-22 08:57:45 toffoo has quit ()
 352 2013-07-22 08:58:02 vbuterin has joined
 353 2013-07-22 08:59:07 B0g4r7 has quit (Ping timeout: 240 seconds)
 354 2013-07-22 09:00:58 agnostic98 has joined
 355 2013-07-22 09:04:38 agnostic98 has quit (Read error: Connection reset by peer)
 356 2013-07-22 09:04:43 B0g4r7 has joined
 357 2013-07-22 09:13:07 iwilcox_ has joined
 358 2013-07-22 09:13:19 iwilcox has quit (Ping timeout: 246 seconds)
 359 2013-07-22 09:18:58 iwilcox_ has quit (Ping timeout: 264 seconds)
 360 2013-07-22 09:19:07 iwilcox_ has joined
 361 2013-07-22 09:21:01 <swulf--> sipa: ever seen this one? "bool LoadExternalBlockFile(FILE*, CDiskBlockPos*)() : Deserialize or I/O error caught during load"
 362 2013-07-22 09:21:07 realzies has quit (Ping timeout: 240 seconds)
 363 2013-07-22 09:29:01 rdponticelli has quit (Remote host closed the connection)
 364 2013-07-22 09:30:15 zer0def has quit (Read error: Operation timed out)
 365 2013-07-22 09:32:42 rdponticelli has joined
 366 2013-07-22 09:33:42 GordonG3kko has quit (Remote host closed the connection)
 367 2013-07-22 09:36:34 GordonG3kko has joined
 368 2013-07-22 09:39:15 viperhr has quit (Quit: Leaving)
 369 2013-07-22 09:41:22 cypher has quit (Ping timeout: 240 seconds)
 370 2013-07-22 09:42:05 cypher has joined
 371 2013-07-22 09:42:58 andyh2 has quit (Quit: Leaving...)
 372 2013-07-22 09:43:54 paraipan has joined
 373 2013-07-22 09:51:41 zer0def has joined
 374 2013-07-22 09:52:18 copumpkin has quit (Ping timeout: 248 seconds)
 375 2013-07-22 09:52:57 copumpkin has joined
 376 2013-07-22 09:56:32 rdponticelli has quit (Quit: No Ping reply in 180 seconds.)
 377 2013-07-22 09:56:42 rdponticelli_ has joined
 378 2013-07-22 10:08:01 slush has quit (Ping timeout: 268 seconds)
 379 2013-07-22 10:08:27 macboz has quit (Quit: This computer has gone to sleep)
 380 2013-07-22 10:20:46 slush has joined
 381 2013-07-22 10:30:08 Jasmin68k has joined
 382 2013-07-22 10:31:05 imton has joined
 383 2013-07-22 10:31:35 vbuterin has quit (Ping timeout: 264 seconds)
 384 2013-07-22 10:33:19 agnostic98 has joined
 385 2013-07-22 10:34:46 c0rw1n has joined
 386 2013-07-22 10:35:18 Diablo-D3 has quit (Quit: This computer has gone to sleep)
 387 2013-07-22 10:35:51 Diablo-D3 has joined
 388 2013-07-22 10:37:29 agnostic98 has quit (Read error: Connection reset by peer)
 389 2013-07-22 10:43:45 vbuterin has joined
 390 2013-07-22 10:47:10 daybyter has joined
 391 2013-07-22 10:48:22 vbuterin has quit (Ping timeout: 264 seconds)
 392 2013-07-22 10:49:31 MCM-Mike_ has left ()
 393 2013-07-22 10:49:48 MCM-Mike has joined
 394 2013-07-22 10:51:36 avyd has joined
 395 2013-07-22 10:52:02 macboz has joined
 396 2013-07-22 10:56:11 macboz has quit (Ping timeout: 245 seconds)
 397 2013-07-22 10:56:58 macboz has joined
 398 2013-07-22 10:57:42 ralphtheninja has joined
 399 2013-07-22 11:04:24 agnostic98 has joined
 400 2013-07-22 11:07:15 agnostic98 has quit (Read error: Connection reset by peer)
 401 2013-07-22 11:09:22 one_zero has quit ()
 402 2013-07-22 11:11:35 platoscave has quit (Quit: http://www.eradicategatesfoundation.com/)
 403 2013-07-22 11:15:39 elgrecoFL has quit (Changing host)
 404 2013-07-22 11:15:39 elgrecoFL has joined
 405 2013-07-22 11:25:36 owowo has joined
 406 2013-07-22 11:30:22 gjj has quit (Remote host closed the connection)
 407 2013-07-22 11:30:49 gjj has joined
 408 2013-07-22 11:32:47 gjj_ has joined
 409 2013-07-22 11:35:29 agnostic98 has joined
 410 2013-07-22 11:35:47 gjj has quit (Read error: Operation timed out)
 411 2013-07-22 11:37:51 B0g4r7 has quit (Ping timeout: 245 seconds)
 412 2013-07-22 11:38:29 agnostic98 has quit (Read error: Connection reset by peer)
 413 2013-07-22 11:42:29 Sealy has joined
 414 2013-07-22 11:46:02 <imton> guys, good morning :)
 415 2013-07-22 11:46:29 <imton> sips is there a way to get bitcoind push me when a new tx is made to and address?
 416 2013-07-22 11:46:33 <imton> ipa
 417 2013-07-22 11:46:34 <imton> sipa
 418 2013-07-22 11:46:48 B0g4r7 has joined
 419 2013-07-22 11:46:56 CheckDavid has joined
 420 2013-07-22 11:47:06 <imton> I want to implement a websockets and I need bitcoind to notify me when a new tx is made to an address instead of polling it
 421 2013-07-22 11:47:45 <sipa> -walletnotify
 422 2013-07-22 11:48:43 <imton> oh….
 423 2013-07-22 11:49:12 <imton> but… if I had hundreds of addresses (may be thousands) … will it scale?
 424 2013-07-22 11:49:17 <sipa> unlikely
 425 2013-07-22 11:49:24 <imton> :(
 426 2013-07-22 11:49:38 <imton> what do you recommend me?
 427 2013-07-22 11:49:47 <sipa> also, afaik, it doesn't support your use case anyway
 428 2013-07-22 11:49:57 <sipa> as it only notifies you for transactions to your wallet addresses
 429 2013-07-22 11:50:01 <imton> yeah...
 430 2013-07-22 11:50:17 <sipa> i think there are better tools around than bitcoind
 431 2013-07-22 11:50:21 <sipa> for what you're doing
 432 2013-07-22 11:50:24 <sipa> at least for now
 433 2013-07-22 11:50:53 <imton> well, I reached a really good implementation yesterday -finally-
 434 2013-07-22 11:51:16 <imton> I get all the info from searchfromrawtransactions and mix it with mempool too, I am kind of happy :)
 435 2013-07-22 11:52:14 <imton> sipa http://cl.ly/QNUL
 436 2013-07-22 11:52:44 <imton> so, first of all thank you for writing that rpc that you hate most :)
 437 2013-07-22 11:52:48 <imton> spia
 438 2013-07-22 11:52:50 <imton> sipa
 439 2013-07-22 11:55:07 CodesInChaos has joined
 440 2013-07-22 11:57:04 <imton> sipa: my idea was to have a service polling the mempool and finding if that txs cotain any of the addresses requested. May be 1 sec delay. will that work?
 441 2013-07-22 11:57:45 <imton> sipa: so then i only have 1 service polling not each client refreshing the site so frequently (which they will do any ways)
 442 2013-07-22 12:01:24 imton has quit (Quit: imton)
 443 2013-07-22 12:03:07 cads has quit (Ping timeout: 240 seconds)
 444 2013-07-22 12:05:39 Yoder has joined
 445 2013-07-22 12:06:09 macboz has quit (Quit: Leaving)
 446 2013-07-22 12:06:31 agnostic98 has joined
 447 2013-07-22 12:09:06 macboz has joined
 448 2013-07-22 12:09:50 agnostic98 has quit (Read error: Connection reset by peer)
 449 2013-07-22 12:11:22 cads has joined
 450 2013-07-22 12:13:53 xnyhps has quit (Read error: Operation timed out)
 451 2013-07-22 12:14:06 xnyhps has joined
 452 2013-07-22 12:22:42 David_ has joined
 453 2013-07-22 12:22:47 ericmuys_ has quit (Read error: Connection reset by peer)
 454 2013-07-22 12:23:20 ericmuyser has joined
 455 2013-07-22 12:23:43 justusranvier has quit (Ping timeout: 240 seconds)
 456 2013-07-22 12:24:33 justusranvier has joined
 457 2013-07-22 12:24:55 CheckDavid has quit (Ping timeout: 264 seconds)
 458 2013-07-22 12:26:22 daybyter has quit (Read error: Connection reset by peer)
 459 2013-07-22 12:28:20 Yoder has quit ()
 460 2013-07-22 12:28:49 David_ has quit (Quit: Leaving)
 461 2013-07-22 12:28:54 MobPhone_ is now known as MobPhone
 462 2013-07-22 12:29:02 agricocb has quit (Quit: Leaving.)
 463 2013-07-22 12:37:36 agnostic98 has joined
 464 2013-07-22 12:38:16 imton has joined
 465 2013-07-22 12:41:29 agnostic98 has quit (Read error: Connection reset by peer)
 466 2013-07-22 12:48:48 cads has quit (Ping timeout: 246 seconds)
 467 2013-07-22 12:49:57 agricocb has joined
 468 2013-07-22 12:51:30 cads has joined
 469 2013-07-22 12:53:11 c0rw1n has quit (Remote host closed the connection)
 470 2013-07-22 12:57:47 patcon has joined
 471 2013-07-22 12:59:15 malaimo has quit (Remote host closed the connection)
 472 2013-07-22 13:01:41 cads has quit (Ping timeout: 256 seconds)
 473 2013-07-22 13:04:51 patcon has quit (Remote host closed the connection)
 474 2013-07-22 13:06:24 Lolcust has quit (Ping timeout: 264 seconds)
 475 2013-07-22 13:07:31 Lolcust has joined
 476 2013-07-22 13:08:20 agnostic98 has joined
 477 2013-07-22 13:09:12 iwilcox_ is now known as iwilcox
 478 2013-07-22 13:10:07 c0rw1n has joined
 479 2013-07-22 13:11:58 agnostic98 has quit (Read error: Connection reset by peer)
 480 2013-07-22 13:17:53 realzies has joined
 481 2013-07-22 13:18:14 realzies is now known as Guest20828
 482 2013-07-22 13:22:31 Guest20828 has quit (Ping timeout: 264 seconds)
 483 2013-07-22 13:25:12 slush has quit (Ping timeout: 240 seconds)
 484 2013-07-22 13:26:46 yubrew has quit (Remote host closed the connection)
 485 2013-07-22 13:27:15 Sealy has quit (Quit: Sealy)
 486 2013-07-22 13:30:46 guruvan has quit (Remote host closed the connection)
 487 2013-07-22 13:30:58 mintmoneyman has joined
 488 2013-07-22 13:31:05 GordonG3kko has quit (Remote host closed the connection)
 489 2013-07-22 13:32:02 guruvan has joined
 490 2013-07-22 13:33:12 btsec has joined
 491 2013-07-22 13:35:10 guyguyguyguy has quit (Ping timeout: 248 seconds)
 492 2013-07-22 13:40:33 cc_8 has joined
 493 2013-07-22 13:41:11 GordonG3kko has joined
 494 2013-07-22 13:45:09 cyrozap has joined
 495 2013-07-22 13:46:42 alexwaters has joined
 496 2013-07-22 13:46:42 alexwaters has quit (Changing host)
 497 2013-07-22 13:46:42 alexwaters has joined
 498 2013-07-22 13:51:07 yubrew has joined
 499 2013-07-22 13:51:18 cyrozap has quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
 500 2013-07-22 13:53:18 cyrozap has joined
 501 2013-07-22 13:57:44 darkee_ has joined
 502 2013-07-22 13:58:09 darkee has quit (Remote host closed the connection)
 503 2013-07-22 14:00:35 Squidicuz has joined
 504 2013-07-22 14:04:33 Guest92286 has left ()
 505 2013-07-22 14:05:00 EPiSKiNG- has joined
 506 2013-07-22 14:05:31 darkee_ has quit (Remote host closed the connection)
 507 2013-07-22 14:05:36 nonick has joined
 508 2013-07-22 14:09:14 patcon has joined
 509 2013-07-22 14:09:40 agnostic98 has joined
 510 2013-07-22 14:12:12 tcatm has quit (Remote host closed the connection)
 511 2013-07-22 14:12:29 Jasmin68k has quit (Ping timeout: 276 seconds)
 512 2013-07-22 14:12:30 tcatm has joined
 513 2013-07-22 14:13:02 phma has quit (Quit: Konversation terminated!)
 514 2013-07-22 14:13:36 mintmoneyman has quit (Quit: Leaving)
 515 2013-07-22 14:13:39 slush has joined
 516 2013-07-22 14:14:03 agnostic98 has quit (Read error: Connection reset by peer)
 517 2013-07-22 14:15:01 jgarzik has joined
 518 2013-07-22 14:15:14 <jgarzik> mornin'
 519 2013-07-22 14:16:04 <sipa> 'fternoon
 520 2013-07-22 14:26:52 mintmoney has joined
 521 2013-07-22 14:27:44 CheckDavid has joined
 522 2013-07-22 14:33:07 <jgarzik> sipa, RE #2840, what is cs_main supposed to cover?  Just "main message processing"?
 523 2013-07-22 14:33:11 KillYourTV has quit (Remote host closed the connection)
 524 2013-07-22 14:33:27 <jgarzik> asking "supposed to cover" not "does cover"
 525 2013-07-22 14:34:18 KillYourTV has joined
 526 2013-07-22 14:38:46 jeewee has joined
 527 2013-07-22 14:39:49 realzies has joined
 528 2013-07-22 14:40:14 realzies is now known as Guest29884
 529 2013-07-22 14:40:21 <Vinnie_win> You guys ever gonna merge my pull request for leveldb?
 530 2013-07-22 14:40:46 agnostic98 has joined
 531 2013-07-22 14:41:22 arioBarzan has joined
 532 2013-07-22 14:43:15 Jasmin68k has joined
 533 2013-07-22 14:43:25 Guest29884 has quit (Changing host)
 534 2013-07-22 14:43:25 Guest29884 has joined
 535 2013-07-22 14:43:26 agnostic98 has quit (Read error: Connection reset by peer)
 536 2013-07-22 14:43:31 Guest29884 is now known as realzies
 537 2013-07-22 14:46:53 <sipa> Vinnie_win: sorry, i've had very little time
 538 2013-07-22 14:47:09 <sipa> Vinnie_win: i've created a leveldb repo under bitcoin, but still haven't found the time to learn git subtree
 539 2013-07-22 14:47:21 B0g4r7_ has joined
 540 2013-07-22 14:47:42 <sipa> jgarzik: cs_main is our main (!) source of non-parallellism really
 541 2013-07-22 14:47:54 <sipa> jgarzik: as pretty much everything locks it (apart from the network thread)
 542 2013-07-22 14:48:15 <jgarzik> Vinnie_win, ditto sipa
 543 2013-07-22 14:48:44 <sipa> Vinnie_win: anyway, there's consensus i think to use that mechanism
 544 2013-07-22 14:48:46 GordonG3kko has quit (Remote host closed the connection)
 545 2013-07-22 14:49:07 <sipa> Vinnie_win: and there are also no roadblocks to upgrading to a newer leveldb
 546 2013-07-22 14:50:30 <sipa> jgarzik: i'm working on headers-first syncing (it's currently working perfectly, except it is headers-first-and-then-nothing), and i think i'll find more code that unnecessarily locks cs_main
 547 2013-07-22 14:51:16 <sipa> jgarzik: in particular, cs_main protects modifications to mapBlockIndex, vBlockIndexByHeight, the chainstate, and pretty much all main.cpp globals
 548 2013-07-22 14:52:07 <jgarzik> sipa, so the public block chain engine
 549 2013-07-22 14:52:19 Jamesz has joined
 550 2013-07-22 14:52:19 * jgarzik kicks OSX autocorrect.  blockchain dammit.
 551 2013-07-22 14:52:51 jedunnigan has joined
 552 2013-07-22 14:53:18 JZavala has quit (Ping timeout: 256 seconds)
 553 2013-07-22 14:53:26 Apexseals has quit (Ping timeout: 256 seconds)
 554 2013-07-22 14:54:03 Apexseals has joined
 555 2013-07-22 14:55:23 rdponticelli_ has quit (Ping timeout: 240 seconds)
 556 2013-07-22 14:55:48 alexwaters has quit (Remote host closed the connection)
 557 2013-07-22 14:58:09 <sipa> jgarzik: that blacklist rpc and reduce cs_main are just two things i've found while working on headers-first
 558 2013-07-22 14:58:53 <sipa> as that will probably result in more edge-cases in reorganizations
 559 2013-07-22 15:02:35 Subo1978_ has joined
 560 2013-07-22 15:03:07 thrasher` has quit (Ping timeout: 240 seconds)
 561 2013-07-22 15:04:23 <jgarzik> sipa, headers-first or reverse-headers-first?
 562 2013-07-22 15:04:42 <jgarzik> sipa, We still don't have anyway to find (a) best chain or (b) locator from remote P2P node, correct?
 563 2013-07-22 15:04:57 GordonG3kko has joined
 564 2013-07-22 15:05:32 rdponticelli has joined
 565 2013-07-22 15:06:23 Subo1978 has quit (Ping timeout: 240 seconds)
 566 2013-07-22 15:07:07 arioBarzan has quit (Remote host closed the connection)
 567 2013-07-22 15:07:26 <sipa> jgarzik: it uses the 'headers' command to do a forward sync of the best chain, validating syntactic correctness and PoW
 568 2013-07-22 15:10:02 <sipa> jgarzik: and then afterwards (well, really simultaneously), starts fetching blocks along this chain (it already knows it is the best one), and connects them
 569 2013-07-22 15:10:17 <sipa> advantage is that you can do out-of-order block fetching
 570 2013-07-22 15:10:46 <sipa> and don't need checkpoints for efficiently (you can set a rule like "don't validate signatures if buried under 3 months of blocks")
 571 2013-07-22 15:10:57 <sipa> and always know whether you're up-to-date or not
 572 2013-07-22 15:11:49 agnostic98 has joined
 573 2013-07-22 15:12:00 <petertodd> nice: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f turns out SIGHASH_SINGLE is a valid flag, even without a corresponding txout, SignatureHash() printf()'s an error, but it returns 1, which is duitifully checked and the tx goes through...
 574 2013-07-22 15:12:19 <sipa> jgarzik: and there is no more concept of orphan blocks... you never fetch a block that you can't connect in the first place
 575 2013-07-22 15:12:23 <petertodd> bitcoin-ruby doesn't handle this case, so webbtc.com just stopped working for instance
 576 2013-07-22 15:12:43 <CodeShar_> +10 for sipa's proposal :)
 577 2013-07-22 15:13:12 daybyter has joined
 578 2013-07-22 15:13:18 CodeShar_ has quit ()
 579 2013-07-22 15:13:39 CodeShark has joined
 580 2013-07-22 15:14:19 <CodeShark> +10 for sipa's proposal
 581 2013-07-22 15:14:32 <sipa> headers-first or the timestamp thing?
 582 2013-07-22 15:15:02 <CodeShark> headers-first plus sliding validation window
 583 2013-07-22 15:15:41 <sipa> i have assumed for a long time that this was the accepted way-to-go
 584 2013-07-22 15:15:46 <sipa> just never found time to work on it
 585 2013-07-22 15:15:54 <CodeShark> ok, then +10 for sipa's attempt at implementing it :)
 586 2013-07-22 15:16:03 agnostic98 has quit (Read error: Connection reset by peer)
 587 2013-07-22 15:16:38 <sipa> currently is synchronizes headers, and if fed a block, it will download, validate, store and try to connect it
 588 2013-07-22 15:16:49 <sipa> but there needs to be some code to decide what block to fetch from where :)
 589 2013-07-22 15:17:25 normanrichards has joined
 590 2013-07-22 15:17:29 <CodeShark> eventually might be nice to add better prioritization of peers
 591 2013-07-22 15:17:50 <sipa> that may not even be needed
 592 2013-07-22 15:18:33 <sipa> just maintain how many 'outstanding' blocks you can have for each peer, and distribute the first N blocks that you don't have to them
 593 2013-07-22 15:19:01 <sipa> if one peer is holding you up, decrease its max number of blocks
 594 2013-07-22 15:19:17 <CodeShark> well, even if you receive invalid block headers, at least you can stop wasting precious resources as soon as you realize it does not connect :)
 595 2013-07-22 15:19:43 <sipa> it's really nice to see how simple ProcessBlock & co become :p
 596 2013-07-22 15:19:51 <CodeShark> indeed
 597 2013-07-22 15:19:54 imton has quit (Quit: imton)
 598 2013-07-22 15:20:25 <jgarzik> sipa, nice
 599 2013-07-22 15:20:38 tsche has quit ()
 600 2013-07-22 15:21:19 BTCOxygen is now known as Guest20487
 601 2013-07-22 15:21:19 BTCOxygen has joined
 602 2013-07-22 15:21:19 Guest20487 has quit (Killed (hubbard.freenode.net (Nickname regained by services)))
 603 2013-07-22 15:21:19 BTCOxygen is now known as 1!~BTCOxygen@unaffiliated/oxygen|BTCOxygen
 604 2013-07-22 15:21:36 imton has joined
 605 2013-07-22 15:21:47 <jgarzik> sipa, it's relevant in my JavaScript work too, because I'm writing header sync in the SPV JS client right now
 606 2013-07-22 15:22:00 <sipa> header sync is really easy
 607 2013-07-22 15:22:13 metabyte has quit (Read error: Connection reset by peer)
 608 2013-07-22 15:22:19 <jgarzik> yep
 609 2013-07-22 15:22:35 metabyte has joined
 610 2013-07-22 15:22:57 <sipa> and SPV is really header-first sync, with block-sync replaced by some wallet-aware optimized selective to-wallet-only-download
 611 2013-07-22 15:23:00 <CodeShark> plus if the logic for building the header tree is separate from the logic for block validation, the header tree code can be readily reused in SPV
 612 2013-07-22 15:23:05 <sipa> ^
 613 2013-07-22 15:24:40 <petertodd> re: SIGHASH_SINGLE libbitcoin handles that case incorrectly too...
 614 2013-07-22 15:24:52 <jgarzik> Yah, I'm making "find best chain" (header sync) an entirely separate process, before wallet (merkle block) sync
 615 2013-07-22 15:25:00 <jgarzik> runs first
 616 2013-07-22 15:25:16 gavinandresen has quit (Ping timeout: 246 seconds)
 617 2013-07-22 15:26:09 <sipa> jgarzik: header sync takes 49s for me :)
 618 2013-07-22 15:26:39 jgarzik has left ("Leaving")
 619 2013-07-22 15:26:46 jgarzik has joined
 620 2013-07-22 15:26:49 <CodeShark> the most expensive operations for header sync are network and db insertion
 621 2013-07-22 15:27:34 <sipa> it actually does take 20-30% CPU while syncing
 622 2013-07-22 15:27:42 <helo> after header sync, chain downloading can be done efficiently ala bittorrent?
 623 2013-07-22 15:27:43 <sipa> and all the rest is network latency
 624 2013-07-22 15:27:52 <sipa> helo: yes
 625 2013-07-22 15:28:31 <gmaxwell> It'll be good when this leaves us looking to merge back in faster sha256 code. :P
 626 2013-07-22 15:29:11 <CodeShark> a couple generations down the line, perhaps Intel chips will have sha in hardware :p
 627 2013-07-22 15:29:15 <jgarzik> sipa, is your address index merge-ready?
 628 2013-07-22 15:29:48 <sipa> jgarzik: it could be, but the latest changes are pretty much untested
 629 2013-07-22 15:29:58 <jgarzik> sipa, ok
 630 2013-07-22 15:31:23 <jgarzik> sipa, also, RE "easy block explorer", I'm strongly tempted to add a REST interface.  Initial target is "GET /rest/tx/$txid" (iff txindex=1) and "GET /rest/block/$blkid", serve as binary|hex|json expansion
 631 2013-07-22 15:31:27 agnostic98 has joined
 632 2013-07-22 15:31:32 <jgarzik> gmaxwell, ^
 633 2013-07-22 15:31:44 c0rw1n has quit (Remote host closed the connection)
 634 2013-07-22 15:31:50 <jgarzik> any objections?
 635 2013-07-22 15:32:02 <petertodd> jgarzik: ACK
 636 2013-07-22 15:32:22 <petertodd> jgarzik: Also /rest/searchtx/$pushdata
 637 2013-07-22 15:32:25 gavinandresen has joined
 638 2013-07-22 15:32:34 GordonG3kko has quit (Remote host closed the connection)
 639 2013-07-22 15:32:40 <jgarzik> sipa, also, RE "easy block explorer", I'm strongly tempted to add a REST interface.  Initial target is "GET /rest/tx/$txid" (iff txindex=1) and "GET /rest/block/$blkid", serve as binary|hex|json expansion
 640 2013-07-22 15:32:43 <sipa> jgarzik: have you seen overblock?
 641 2013-07-22 15:32:45 <jgarzik> gavinandresen, ^  (resend)
 642 2013-07-22 15:32:49 <jgarzik> sipa, no
 643 2013-07-22 15:33:04 <sipa> jgarzik: it's a python blockexplorer-like webserver using bitcoind RPC
 644 2013-07-22 15:33:11 <sipa> using txindex
 645 2013-07-22 15:33:29 <sipa> realazthat wrote it; it would be nice if addrindex support got added
 646 2013-07-22 15:33:53 <jgarzik> cool
 647 2013-07-22 15:33:54 <sipa> https://github.com/realazthat/overblock
 648 2013-07-22 15:34:11 <realzies> mmmm
 649 2013-07-22 15:34:13 <realzies> hi sipa
 650 2013-07-22 15:34:17 <jgarzik> I always read his name as "real ass hat" (though I'm sure he's an awesome fellow)
 651 2013-07-22 15:34:23 <realzies> lol
 652 2013-07-22 15:34:26 <sipa> i read it as "realize that"
 653 2013-07-22 15:34:32 <realzies> real az that :P
 654 2013-07-22 15:34:43 jeewee has quit (Quit: Leaving.)
 655 2013-07-22 15:34:47 <sipa> real as dad?
 656 2013-07-22 15:34:58 <realzies> lol
 657 2013-07-22 15:35:00 btcera has joined
 658 2013-07-22 15:35:27 <realzies> I am away from home atm, but I'll talk more about addrindex when I get back
 659 2013-07-22 15:36:05 <gmaxwell> I tried the overblock stuff and found it to be pretty neat.
 660 2013-07-22 15:36:32 t7 has quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
 661 2013-07-22 15:37:26 <gmaxwell> I'd encourage that whatever interface we offer something like that on have no access to private data, for risk of some kind of JS injection through block data. :P Certantly would be awesome to have more integrated explorer stuff... that is what the varrious indexes are for. :P
 662 2013-07-22 15:37:33 GordonG3kko has joined
 663 2013-07-22 15:38:06 <petertodd> gmaxwell: Good idea, people *will* expose it to the web to others in all sorts of dumb ways, or to themselves.
 664 2013-07-22 15:40:19 <CodeShark> you should never be using these things on an instance of bitcoind you also use as a wallet :p;
 665 2013-07-22 15:40:31 <CodeShark> there's absolutely no need to
 666 2013-07-22 15:40:51 PrimeStunna has joined
 667 2013-07-22 15:40:53 <realzies> heh
 668 2013-07-22 15:40:57 <CodeShark> in fact, the vast majority of my bitcoind instances, I never even touch the wallet
 669 2013-07-22 15:41:01 <petertodd> Well, a local blockexplorer is useful, so people will do just that...
 670 2013-07-22 15:41:11 <CodeShark> I just leave it there because the damn thing won't load without a wallet.dat file
 671 2013-07-22 15:41:13 <realzies> yeah it wasn't meant to be "secure", but I am not going to try to introduce vulnerabilities
 672 2013-07-22 15:41:28 <gmaxwell> Considering how 'costly' running a bitcoind instance is ... its hard to tell most people that.
 673 2013-07-22 15:41:33 <jgarzik> Let's just delete the wallet and go home.
 674 2013-07-22 15:41:40 <jgarzik> or shopping
 675 2013-07-22 15:41:46 <gmaxwell> I do most of my bitcoind usage on the actual network on something with a wallet that has some coin in it.
 676 2013-07-22 15:42:01 <sipa> i'm really in the middle here
 677 2013-07-22 15:42:22 <sipa> i dislike all indexing functionality that can be abused to build non-scalable solutions
 678 2013-07-22 15:42:39 <sipa> but if it can get people to run more fully-validating nodes because they like a local blockexplorer...
 679 2013-07-22 15:42:50 <jgarzik> BitPay is moving away from bitcoind as a wallet, but continues to see bitcoind in the role of Industrial Strength P2P Node </vendor hat>
 680 2013-07-22 15:43:03 <jgarzik> i.e. public blockchain engine
 681 2013-07-22 15:43:04 <sipa> makes perfect sense
 682 2013-07-22 15:43:06 <gmaxwell> I also dislike people depending on centeralized blockexplorers, esp the fact that there is basically only one that people use.
 683 2013-07-22 15:43:38 <CodeShark> the bitcoind wallet was NEVER designed nor intended to be used for enterprise app development
 684 2013-07-22 15:43:45 <CodeShark> it's clearly a single end-user model
 685 2013-07-22 15:44:13 <gmaxwell> And yea, it sucks when we don't get to have missing footguns to encourage people to not use footguns. But there is only so much responsiblity we can take for what crazy things people do. If leaving out an index makex them use the bc.i API or run some squirlly alternative full node, thats worse.
 686 2013-07-22 15:44:33 jeewee has joined
 687 2013-07-22 15:44:35 <CodeShark> anyone who uses it for things like running web stores is already abusing bitcoind to build a nonscalable solution
 688 2013-07-22 15:44:56 <jgarzik> heh
 689 2013-07-22 15:45:00 tsche has joined
 690 2013-07-22 15:45:37 <jgarzik> part of what sucks about that is a lack of docs for merchants, telling them how to build a secure web store, how to manage keys securely
 691 2013-07-22 15:45:54 Gnaf has quit (Quit: for (i = first; i < size; i += prime) marked[i] = 1;)
 692 2013-07-22 15:46:36 <gmaxwell> CodeShark: I dunno, its a little less bad than you're giving it credit for. Go rig IsMine to return true on 1% of the total transactions and resync the chain... it does actually work.
 693 2013-07-22 15:47:17 <gmaxwell> CodeShark: there are plenty of other reasons to not do that, but with a little profiling and kicking I don't see that there are any basic mechnical scalablity issues with using it to receive/send txn (not accounting, of course)
 694 2013-07-22 15:47:38 <sipa> meh
 695 2013-07-22 15:47:50 <gmaxwell> CodeShark: you have to rotate out wallets periodically right now if you're a big user, but this isn't a huge burden.
 696 2013-07-22 15:47:57 <sipa> even just rpc as an interface makes it pretty bad as a solution
 697 2013-07-22 15:48:11 <sipa> -walletnotify is nice but doesn't scale to high transaction rates really
 698 2013-07-22 15:48:17 <CodeShark> absolutely - walletpassphrase?! for RPC?
 699 2013-07-22 15:48:26 <CodeShark> no access controls (unless you build your own proxy)?
 700 2013-07-22 15:48:33 <CodeShark> absolutely horrid concurrency?
 701 2013-07-22 15:48:46 <sipa> what concurrency are you talking about? :o
 702 2013-07-22 15:48:52 <swulf--> sipa: i added a listtransactions2 call that makes use of bitcoind for processing transactions a tiny bit more convenient
 703 2013-07-22 15:49:05 talso has quit (Ping timeout: 260 seconds)
 704 2013-07-22 15:49:06 <gmaxwell> CodeShark: access controlls aren't enormously important. And what the heck do you need concurency for? the whole rate of the network is relativly limited.
 705 2013-07-22 15:49:50 <gmaxwell> CodeShark: the fine tradition of really solid access control is upheld: run another copy for another security domain. :P
 706 2013-07-22 15:49:53 <CodeShark> access controls are immensely important when you don't want to give your web developers full reign over all accounts or want to send alerts when thresholds are exceeded
 707 2013-07-22 15:51:12 macboz has quit (Ping timeout: 245 seconds)
 708 2013-07-22 15:51:33 <gmaxwell> CodeShark: what the heck would you be doing with using a production wallet in development?  In practice most businesses _in the world_ do not have enough tech staff that you could firewallet techstaff with wallet access and ones that don't. That isn't to say that there aren't many that do, but I think you're overgeneralizing the needs of the very largest.
 709 2013-07-22 15:51:43 <CodeShark> as for concurrency, it could mean a user having to wait several more seconds (at least) before their view updates
 710 2013-07-22 15:52:09 <gmaxwell> ...
 711 2013-07-22 15:52:14 <CodeShark> and that's assuming low volume
 712 2013-07-22 15:52:35 <CodeShark> not all RPC wallet commands send transactions
 713 2013-07-22 15:52:44 <gmaxwell> thats nonsense. If you're using a thread per user to access bitcoind you're using a broken design.
 714 2013-07-22 15:52:58 <CodeShark> you don't need a thread per user
 715 2013-07-22 15:53:07 <CodeShark> you could even use a single thread that handles requests asynchronously
 716 2013-07-22 15:53:07 <gmaxwell> You could change bitcoind to accomidate your design, true. Or you could not use one that doesn't work with it.
 717 2013-07-22 15:53:27 <gmaxwell> CodeShark: then you wouldn't have the head of line blocking you propose.
 718 2013-07-22 15:53:30 <sipa> i think the point is that eventually, you'll not be server account balances or transaction lists from bitcoind on the serving path
 719 2013-07-22 15:53:37 <sipa> for any decent volume of traffic
 720 2013-07-22 15:53:47 <sipa> even though those are tasks it is designed for
 721 2013-07-22 15:54:20 <CodeShark> there's also the issue of separation of signing from verification/receiving
 722 2013-07-22 15:54:24 <CodeShark> which I've been harping on for so long :p
 723 2013-07-22 15:54:31 <gmaxwell> Certantly the accounting stuff is worthless, it simply fails on a durability perspective if nothing else.
 724 2013-07-22 15:54:54 PrimeStunna has quit (Quit: PrimeStunna)
 725 2013-07-22 15:54:55 <gmaxwell> I use it for personal notes to simplyify my taxes and thats about all its good for.
 726 2013-07-22 15:55:22 <CodeShark> the correct model for a merchant receiving bitcoin payments,
 727 2013-07-22 15:55:25 <CodeShark> IMHO
 728 2013-07-22 15:55:27 <CodeShark> ...
 729 2013-07-22 15:55:28 <CodeShark> is
 730 2013-07-22 15:55:43 <CodeShark> running several verification/relay nodes that forward messages over to a message broker
 731 2013-07-22 15:55:56 talso has joined
 732 2013-07-22 15:56:06 <CodeShark> or a cluster of them
 733 2013-07-22 15:56:16 <CodeShark> and being able to subscribe and ack all messages
 734 2013-07-22 15:56:21 <gmaxwell> it can be really easy in the model to build exploitable site specific code.
 735 2013-07-22 15:56:52 <gmaxwell> Not that that is a killer or anything, but a tradeoff in highly decopled things is that you end up with a lot of gnarly bitcoin logic in multiple tools that way.
 736 2013-07-22 15:57:09 <CodeShark> the correct model for a merchant sending bitcoin payments is requesting a signature from a signing-only node sitting behind a firewall (or running on dedicated hardware)
 737 2013-07-22 15:57:59 <gmaxwell> IMO if you're doing both these things in realtime, you're a bank-like service, and you're instantly into the realm of very specialized and difficult to secure problems.
 738 2013-07-22 15:58:21 <gmaxwell> because there are a bunch of vulnerablities that are impratical to have unless you automatically both send and recieve.
 739 2013-07-22 15:58:21 <CodeShark> I believe all these tools can become commoditized and simple to use with proper design
 740 2013-07-22 15:59:31 <CodeShark> I believe the correct model for key generation is either deterministic type 2 keys or batch pregeneration and synching of address pools with invoicing servers
 741 2013-07-22 16:00:05 <CodeShark> it would be fairly simple to develop tools to ensure synchronization
 742 2013-07-22 16:00:18 <CodeShark> or to warn in the event of synchronization failure
 743 2013-07-22 16:00:26 <gmaxwell> "commoditized and simple" maybe but there are some considerations. For example, I don't think you can ever exposed site specific code to a low confirmed transaction if that code is to be both simple and safe.
 744 2013-07-22 16:00:43 <gmaxwell> s/exposed/expose/
 745 2013-07-22 16:00:56 <CodeShark> confirmation count policy depends on application
 746 2013-07-22 16:01:27 <CodeShark> there can be general guidelines
 747 2013-07-22 16:01:31 <gmaxwell> because otherwise it has to deal with transactions being undone, and this is reasonably difficulty to get right even if you understand the problem. Many people don't understand it, its hard to test, and they may never observe it happen absent an attack.
 748 2013-07-22 16:01:59 <CodeShark> undone transactions would produce messages that the message brokers would also queue up
 749 2013-07-22 16:02:13 <CodeShark> making it easy to handle this logic on the application side
 750 2013-07-22 16:02:15 <gmaxwell> yea, right great, might as well just copy everything on p2p to your message brokers. :P
 751 2013-07-22 16:02:29 <CodeShark> the p2p protocol is far too low level for app developers
 752 2013-07-22 16:02:41 <gmaxwell> as I said, you walk a fine line with requiring all the app logic to safely reimplement a lot of bitcoin stuff.
 753 2013-07-22 16:02:45 <CodeShark> it
 754 2013-07-22 16:02:58 <CodeShark> the p2p protocol is great for two things: verification and relay
 755 2013-07-22 16:03:15 <CodeShark> it's not designed for high level message brokering
 756 2013-07-22 16:03:25 <CodeShark> pub/sub, filtering, topics, etc...
 757 2013-07-22 16:03:56 <gmaxwell> I'm sorry I distracted you with that, you missed my point. P2P is bad for those reasons for that purpose, but it's bad for a whole nother set of them:
 758 2013-07-22 16:04:20 <CodeShark> there's no reimplementation of bitcoin here
 759 2013-07-22 16:04:28 <CodeShark> the bitcoin protocol remains the backbone of the network
 760 2013-07-22 16:04:29 <gmaxwell> which is that it's hard to get the bitcoin logic right for even an expert. If you make app developers add a lot of bitcoin specififc logic a lot will get it wrong and be vulnerable as a result.
 761 2013-07-22 16:04:49 <CodeShark> there's no need for the application developers to keep track of all the low level intricacies for things like verification
 762 2013-07-22 16:05:06 <gmaxwell> CodeShark: if you have to undo a transaction triggered from the network, thats bitcoin specific logic that a lot of people will get wrong.
 763 2013-07-22 16:05:07 <CodeShark> they just need to receive messages for when specific types of events occur
 764 2013-07-22 16:05:24 <gmaxwell> If you have to identify if a payment is for you— thats bitcoin specific logic that a lot of people will get wrong.
 765 2013-07-22 16:05:52 <CodeShark> no, it's rather simple to use a filtering message broker
 766 2013-07-22 16:06:09 <CodeShark> provide it with a list of receiving addresses
 767 2013-07-22 16:06:09 <gmaxwell> OK
 768 2013-07-22 16:07:47 <CodeShark> use hash trees to verify that the receiving addresses on different message brokers are synchronized
 769 2013-07-22 16:08:11 <CodeShark> (this functionality would be built into such products, no need for application developers to deal with the low level implementation specifics)
 770 2013-07-22 16:09:19 <CodeShark> application developers should be able to subscribe to messages for events like transaction seen, transaction confirmation count change, etc...
 771 2013-07-22 16:09:44 <CodeShark> and message brokers should ensure that they are synched properly
 772 2013-07-22 16:09:59 <Diablo-D3> CodeShark: yes but
 773 2013-07-22 16:10:00 <Diablo-D3> that'd make sense
 774 2013-07-22 16:10:06 <Diablo-D3> so we obviously cant have that
 775 2013-07-22 16:10:09 <CodeShark> lol
 776 2013-07-22 16:10:41 <sipa> http://abstrusegoose.com/518
 777 2013-07-22 16:11:11 <CodeShark> lol
 778 2013-07-22 16:11:38 <Diablo-D3> sipa: oh dear god, a xkcd clone
 779 2013-07-22 16:11:49 <sipa> a much geekier one
 780 2013-07-22 16:12:45 slush has quit (Ping timeout: 276 seconds)
 781 2013-07-22 16:14:00 <Diablo-D3> so wait
 782 2013-07-22 16:14:03 <Diablo-D3> doe sthat make it funny or not?
 783 2013-07-22 16:14:45 <sipa> for some people, probably
 784 2013-07-22 16:14:51 <sipa> you know
 785 2013-07-22 16:14:55 <Diablo-D3> some people find xkcd funny
 786 2013-07-22 16:14:57 <sipa> de gustibus et coloribus
 787 2013-07-22 16:15:00 iwilcox_ has joined
 788 2013-07-22 16:15:20 iwilcox has quit (Ping timeout: 264 seconds)
 789 2013-07-22 16:15:27 <Diablo-D3> english please
 790 2013-07-22 16:15:45 runeks has joined
 791 2013-07-22 16:16:50 <sipa> Diablo-D3: it's a latin proverb about there's no point discussing differences in taste
 792 2013-07-22 16:17:11 cyrozap has quit (Ping timeout: 264 seconds)
 793 2013-07-22 16:20:22 realzies has quit (Ping timeout: 245 seconds)
 794 2013-07-22 16:20:37 GordonG3kko has quit (Remote host closed the connection)
 795 2013-07-22 16:23:35 David_ has joined
 796 2013-07-22 16:23:48 cyrozap has joined
 797 2013-07-22 16:26:24 CheckDavid has quit (Ping timeout: 276 seconds)
 798 2013-07-22 16:27:53 phma has joined
 799 2013-07-22 16:30:38 yubrew has quit (Remote host closed the connection)
 800 2013-07-22 16:32:29 chmod755 has joined
 801 2013-07-22 16:32:54 arioBarzan has joined
 802 2013-07-22 16:36:26 GordonG3kko has joined
 803 2013-07-22 16:37:52 David_ has quit (Quit: Leaving)
 804 2013-07-22 16:43:47 slush has joined
 805 2013-07-22 16:44:18 yubrew has joined
 806 2013-07-22 16:47:47 [Author] has quit (Ping timeout: 256 seconds)
 807 2013-07-22 16:52:06 santoscork has joined
 808 2013-07-22 16:52:50 [Author] has joined
 809 2013-07-22 16:55:03 dust-otc has joined
 810 2013-07-22 16:55:42 <bakingbread> sipa: you forgot to add "non est disputandum"
 811 2013-07-22 16:56:09 <sipa> bakingbread: not forgotten; abbreviated :)
 812 2013-07-22 16:57:42 peetaur2 has joined
 813 2013-07-22 17:01:14 jeewee has quit (Quit: Leaving.)
 814 2013-07-22 17:01:54 vbuterin has joined
 815 2013-07-22 17:03:25 wamatt has joined
 816 2013-07-22 17:03:37 Pucilowski_ has quit ()
 817 2013-07-22 17:04:01 Pucilowski has joined
 818 2013-07-22 17:05:00 bbrian has joined
 819 2013-07-22 17:05:50 iwilcox_ is now known as iwilcox
 820 2013-07-22 17:07:43 Muis has joined
 821 2013-07-22 17:09:20 zer0def has quit (Ping timeout: 246 seconds)
 822 2013-07-22 17:10:37 santoscork has quit (Quit: Quiet while I make like a cat)
 823 2013-07-22 17:14:49 barmstrong has quit (Quit: barmstrong)
 824 2013-07-22 17:15:59 CodesInChaos has quit (Remote host closed the connection)
 825 2013-07-22 17:17:31 zer0def has joined
 826 2013-07-22 17:19:33 cyrozap has quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
 827 2013-07-22 17:19:47 <gwillen> does anybody have an order-of-magnitude estimate of the current UTXO set size, or know how one might compute it?
 828 2013-07-22 17:20:28 <sipa> ./bitcoind gettxoutsetinfo
 829 2013-07-22 17:20:31 <gmaxwell> gwillen: run gettxoutsetinfo on bitcoind (takes a minute)
 830 2013-07-22 17:20:34 <gwillen> thanks
 831 2013-07-22 17:20:47 ciatron has quit (Ping timeout: 250 seconds)
 832 2013-07-22 17:21:13 <gmaxwell> gwillen: do not that this is just the size of the highly compacted representation seralized. It's larger fully unpacked and/or stuffed into a authentication tree or a database for fast lookups.
 833 2013-07-22 17:21:17 <gmaxwell> s/not/note/
 834 2013-07-22 17:21:19 tcatm_ has joined
 835 2013-07-22 17:21:25 <gwillen> ahh, *nods*
 836 2013-07-22 17:21:52 tcatm has quit (Ping timeout: 245 seconds)
 837 2013-07-22 17:24:24 paracyst has joined
 838 2013-07-22 17:26:03 tcatm_ has quit (Ping timeout: 245 seconds)
 839 2013-07-22 17:26:23 tcatm has joined
 840 2013-07-22 17:26:23 tcatm has quit (Changing host)
 841 2013-07-22 17:26:23 tcatm has joined
 842 2013-07-22 17:27:25 barmstrong has joined
 843 2013-07-22 17:28:02 i2pRelay has quit (Quit: kytv)
 844 2013-07-22 17:28:28 i2pRelay has joined
 845 2013-07-22 17:30:10 i2pRelay has quit (Remote host closed the connection)
 846 2013-07-22 17:32:00 arioBarzan has quit (Remote host closed the connection)
 847 2013-07-22 17:32:32 cc_8 has quit ()
 848 2013-07-22 17:32:47 vbuterin has quit (Ping timeout: 264 seconds)
 849 2013-07-22 17:32:53 i2pRelay has joined
 850 2013-07-22 17:33:03 sensorii has quit (Remote host closed the connection)
 851 2013-07-22 17:33:03 guruvan has quit (Remote host closed the connection)
 852 2013-07-22 17:35:00 brson has joined
 853 2013-07-22 17:37:10 sserrano44 has joined
 854 2013-07-22 17:39:46 iwilcox has quit (Read error: Operation timed out)
 855 2013-07-22 17:39:47 iwilcox_ has joined
 856 2013-07-22 17:44:39 cyrozap has joined
 857 2013-07-22 17:44:55 dust-otc has quit (Remote host closed the connection)
 858 2013-07-22 17:48:00 <TheUni> bitcoind up and running on android if there's any interest
 859 2013-07-22 17:49:04 <gmaxwell> TheUni: really? cool. compiled using the ndk stuff?
 860 2013-07-22 17:49:32 <TheUni> yea
 861 2013-07-22 17:49:49 <TheUni> seems like it'd be a cheap/quick/easy way to get relay nodes up and running
 862 2013-07-22 17:50:37 <TheUni> if there's interest, i could put some time into making it a quick POC apk with a gui that's basically just an on/off switch
 863 2013-07-22 17:53:04 <TheUni> only took about an hour of fiddling to get it patched, compiled and running. pretty uninvasive
 864 2013-07-22 17:54:16 <gmaxwell> TheUni: how long did it take to sync up?
 865 2013-07-22 17:54:44 <TheUni> heh, no clue. just fired it up 10min ago
 866 2013-07-22 17:54:47 jamesonwa has joined
 867 2013-07-22 17:55:29 gjj has joined
 868 2013-07-22 17:55:55 <gmaxwell> TheUni: whats it at now?
 869 2013-07-22 17:56:04 <TheUni> running on a 4core odroid, should be on par with an oldish desktop, i'd think
 870 2013-07-22 17:56:26 Gnaf has joined
 871 2013-07-22 17:56:38 <TheUni> SetBestChain: new best=00000000069d5d70aad5bf72b8d856c821ea41ee1969d803a31fcff91e633350  height=62363  log2_work=49.883994  tx=69725  date=2010-06-23 19:04:12 progress=0.001289
 872 2013-07-22 17:58:54 gjj_ has quit (Ping timeout: 246 seconds)
 873 2013-07-22 18:03:54 <gmaxwell> Thats pretty slow. :( and it's not even to the ecdsa hard parts yet. I suppose I should profile on arm at some point.
 874 2013-07-22 18:05:58 rdymac has quit (Read error: Connection reset by peer)
 875 2013-07-22 18:08:42 <jgarzik> w00t.  HTTP REST framework working.  Now to add /rest/tx/$txid and /rest/block/$blkid
 876 2013-07-22 18:09:02 <petertodd> +1
 877 2013-07-22 18:10:09 jeewee has joined
 878 2013-07-22 18:10:27 rdymac has joined
 879 2013-07-22 18:12:34 iwilcox_ is now known as iwilcox
 880 2013-07-22 18:13:46 <TheUni> gmaxwell: it came up literally 30min ago, completely unoptimized. haven't even run the tests yet
 881 2013-07-22 18:14:13 <TheUni> tbh, i have no idea what it's doing. i can tell from the debug log that it's running, but that's about it
 882 2013-07-22 18:14:40 <TheUni> i was hoping for a quick load+crash, didn't expect it to actually do anything useful :)
 883 2013-07-22 18:15:14 chmod755 has quit (Quit: Leaving)
 884 2013-07-22 18:16:41 <gmaxwell> TheUni: K. Bluematt has had it running on odroids on Ubuntu/Linux for some time. Android is a little more of an accomplishment. :P
 885 2013-07-22 18:17:09 satoshi_ has joined
 886 2013-07-22 18:18:07 <TheUni> well like i said, i haven't actually wrapped it in the typical android-isms yet, i'm just launching from cmdline. No sense wasting time into making it a proper deployable apk if there's no interest in it
 887 2013-07-22 18:18:29 <TheUni> gmaxwell: got any recommendations for gauging ^^ ?
 888 2013-07-22 18:19:30 <gmaxwell> make one once, and then see if people whine at you to update it. :P
 889 2013-07-22 18:19:51 <TheUni> haha
 890 2013-07-22 18:20:32 <TheUni> well i sure as hell wouldn't download a random bitcoind app, so it'd need to be signed with official keys
 891 2013-07-22 18:20:56 <gmaxwell> I'll point out that even if almost no one cares testing the software in weird enviroments can expose serious bugs that we need to also fix for other platforms, so its a good excercise even if people don't use it.
 892 2013-07-22 18:21:41 <TheUni> sure, that's why i work on abstractions and ports, i'm pretty obsessive about exactly that point
 893 2013-07-22 18:22:59 Jamesz has quit (Ping timeout: 256 seconds)
 894 2013-07-22 18:23:36 <TheUni> heh, good proof of that: http://pastebin.com/raw.php?i=bEf1D0SF
 895 2013-07-22 18:24:58 <Luke-Jr> gavinandresen: I'll have a patch to fix that gitian error in a few min
 896 2013-07-22 18:25:51 jedunnigan has quit (Remote host closed the connection)
 897 2013-07-22 18:26:11 normanrichards has quit (Quit: normanrichards)
 898 2013-07-22 18:26:15 <TheUni> Luke-Jr: anything i can do to move the autotools PR along? I have abstraction work that depends on it
 899 2013-07-22 18:27:08 <Luke-Jr> TheUni: dunno, that's a question for wumpus :/
 900 2013-07-22 18:27:23 <Luke-Jr> wumpus: ping, TheUni would appreciate a review from you :p
 901 2013-07-22 18:27:31 <TheUni> Luke-Jr: thanks :)
 902 2013-07-22 18:28:26 satoshi_ has quit (Quit: Page closed)
 903 2013-07-22 18:32:23 Application has quit (Remote host closed the connection)
 904 2013-07-22 18:33:38 Internet13 has quit (Ping timeout: 240 seconds)
 905 2013-07-22 18:34:39 <wumpus> TheUni: that was easy :)
 906 2013-07-22 18:35:04 <TheUni> ?
 907 2013-07-22 18:35:33 <wumpus> I think it was already ok with me last time, so you've got your ack 
 908 2013-07-22 18:35:54 <wumpus> let's just get this in
 909 2013-07-22 18:36:16 <TheUni> aha, great. thanks
 910 2013-07-22 18:36:25 <TheUni> wumpus: not that this time around, i completely ignored qt-creator
 911 2013-07-22 18:36:28 <TheUni> *note
 912 2013-07-22 18:36:39 <TheUni> so, that is all on you :)
 913 2013-07-22 18:36:59 <wumpus> yeah, I understand...
 914 2013-07-22 18:38:22 Internet13 has joined
 915 2013-07-22 18:38:25 <TheUni> ok, perfect. I'll close this one and do a final squashed PR with updated docs and working gitian descriptors
 916 2013-07-22 18:39:52 daybyter has quit (Quit: Konversation terminated!)
 917 2013-07-22 18:39:56 <wumpus> great!
 918 2013-07-22 18:42:15 <TheUni> will be a bit delayed this time around. in-laws coming in from out of the country for the next month, so no clue how much hacking time i'll have
 919 2013-07-22 18:42:44 <wumpus> well if it's just a matter of squashing the commit we could do it too, I suppose
 920 2013-07-22 18:43:47 <TheUni> squashing should be straightfoward, it's gitian and docs that still need love
 921 2013-07-22 18:43:56 <TheUni> i didn't want to do em til the core work was ack'd
 922 2013-07-22 18:48:15 pooler_ has quit (Ping timeout: 246 seconds)
 923 2013-07-22 18:48:39 <wumpus> makes sense
 924 2013-07-22 18:49:22 pooler_ has joined
 925 2013-07-22 18:49:49 <TheUni> will try to find some time in the next week
 926 2013-07-22 18:49:53 <TheUni> thanks for taking another look
 927 2013-07-22 18:54:48 saintcajetan has left ("Leaving")
 928 2013-07-22 19:01:28 TD has joined
 929 2013-07-22 19:03:30 bbrian has quit (Read error: Connection reset by peer)
 930 2013-07-22 19:05:59 Vinnie_win has quit (Read error: Connection reset by peer)
 931 2013-07-22 19:06:01 cads has joined
 932 2013-07-22 19:08:04 Vinnie_win has joined
 933 2013-07-22 19:13:11 <jgarzik> and? REST is working.  Modulo an interpret-binary-data-as-C-string bug.
 934 2013-07-22 19:13:23 <jgarzik> binary, hex and json formats.
 935 2013-07-22 19:13:38 <petertodd> +2
 936 2013-07-22 19:21:24 Application has joined
 937 2013-07-22 19:22:25 Applicat_ has joined
 938 2013-07-22 19:25:42 Application has quit (Ping timeout: 246 seconds)
 939 2013-07-22 19:25:50 <TheUni> jgarzik: mm, as i think about it, android app could be interesting with checkpointing. add a huge number of nodes to the network for relaying unconfirmed transactions. soon as a coin is mined, dump the chain and start over
 940 2013-07-22 19:26:05 <TheUni> even a tiny fraction of android devices doing that would add up to a huge number
 941 2013-07-22 19:27:01 rlifchitz has quit (Ping timeout: 256 seconds)
 942 2013-07-22 19:27:48 grau has quit (Remote host closed the connection)
 943 2013-07-22 19:28:20 deego` has joined
 944 2013-07-22 19:28:20 deego` has quit (Remote host closed the connection)
 945 2013-07-22 19:28:48 deego has quit (Ping timeout: 256 seconds)
 946 2013-07-22 19:29:16 Thepok has joined
 947 2013-07-22 19:30:02 deego` has joined
 948 2013-07-22 19:30:04 <TheUni> er, i suppose the lightweight clients do that already though. nm
 949 2013-07-22 19:30:24 alexwaters has joined
 950 2013-07-22 19:30:24 alexwaters has quit (Changing host)
 951 2013-07-22 19:30:24 alexwaters has joined
 952 2013-07-22 19:30:57 rlifchitz has joined
 953 2013-07-22 19:31:28 jeewee has quit (Quit: Leaving.)
 954 2013-07-22 19:33:34 DoctorBTC has quit (Ping timeout: 260 seconds)
 955 2013-07-22 19:36:28 <jgarzik> REST assured, you are safe to query.  https://github.com/bitcoin/bitcoin/pull/2844
 956 2013-07-22 19:49:33 <MC1984> dohoho
 957 2013-07-22 19:49:59 barmstrong has quit (Quit: barmstrong)
 958 2013-07-22 19:53:22 <gmaxwell> uhhh
 959 2013-07-22 19:53:24 <gmaxwell> fuck
 960 2013-07-22 19:53:39 <gmaxwell> debian is shipping bitcoind patched to use a system leveldb
 961 2013-07-22 19:53:47 <petertodd> ugh
 962 2013-07-22 19:53:48 barmstrong has joined
 963 2013-07-22 19:53:57 <gmaxwell> and it appears to fork on some of the older history
 964 2013-07-22 19:54:48 <petertodd> Can we add something to the Bitcoin source itself to check for the leveldb version, and put a explanatory comment next to that check saying why it's so important to leave leveldb the way it is?
 965 2013-07-22 19:56:38 <gwillen> I would encourage you to have someone _extremely patient_ talk to debian about this
 966 2013-07-22 19:56:45 <gwillen> it will probably have to be explained slowly several times
 967 2013-07-22 19:57:04 <gmaxwell> This actually has been done before.
 968 2013-07-22 19:57:15 <gwillen> heh
 969 2013-07-22 19:57:21 <TheUni> i suppose there are non-upstream'able patches?
 970 2013-07-22 19:57:37 <jgarzik> distros just have a MAJOR compulsion to use system libs
 971 2013-07-22 19:57:48 <gmaxwell> For good reasons in general.
 972 2013-07-22 19:57:48 <jgarzik> embedded libs drive distro hackers bonkers
 973 2013-07-22 19:57:53 <TheUni> as well they should..
 974 2013-07-22 19:58:02 <jgarzik> e.g. having to fix XXX copies of zlib, for each zlib bug
 975 2013-07-22 19:58:08 <gmaxwell> (Also, I'm beginning to think debian is hopeless, they are carrying a number of patches in addition to the system changes which they've never exposed to us before)
 976 2013-07-22 19:58:39 <gmaxwell> TheUni: It isn't a matter of non-upstream'able patches. Its a matter of _fixing_ a bug in any of our network rules centeric code can cause total network failure.
 977 2013-07-22 19:58:48 <gwillen> gmaxwell: you may want to just ask them not to carry it at all
 978 2013-07-22 19:58:53 <gmaxwell> gwillen: We did.
 979 2013-07-22 19:58:55 <gwillen> that seems like a request they may respect
 980 2013-07-22 19:58:56 <gwillen> oh.
 981 2013-07-22 19:59:02 <jgarzik> IMO this is worth explaining in a blog post
 982 2013-07-22 19:59:08 <TheUni> gmaxwell: so an upstream version can never be used, then?
 983 2013-07-22 19:59:10 <jgarzik> because it is non-obvious
 984 2013-07-22 19:59:16 <jgarzik> (outside of bitcoin, to other devs)
 985 2013-07-22 19:59:41 <petertodd> jgarzik: Honestly, put it in a Bitcoin Foundation blog post signed by Gavin.
 986 2013-07-22 19:59:51 <jgarzik> indeed
 987 2013-07-22 19:59:59 <petertodd> jgarzik: On your blog is good too, but we want to be really official about this so people listen.
 988 2013-07-22 20:00:04 <gmaxwell> TheUni: E.g. Say level DB has a bug where any key with a ID that begins with 0xDEADBEEF can not be found. Such bugs can happen here and then in database engines.  Say there is a transaction with 0xDEADBEEF as its previx (perhaps even created by a malicious part).
 989 2013-07-22 20:00:17 <jgarzik> I'm pretty sure people would let me post on the BF blog, if I ask nicely
 990 2013-07-22 20:00:24 <jgarzik> anyway
 991 2013-07-22 20:00:29 jgarzik has quit (Quit: apple apple apple *poof*)
 992 2013-07-22 20:00:34 <gmaxwell> TheUni: if you fix the deadbeef bug, then the network splits into two: fixed nodes and non-fixed nodes.  And whichever side ultimately loses gets all its txn reversed.
 993 2013-07-22 20:00:37 <petertodd> IMO distros shouldn't even package bitcoind due to the security issues, but they already package other libraries so...
 994 2013-07-22 20:00:58 <petertodd> At least the builds we officially release are staticly linked... right?
 995 2013-07-22 20:01:01 <TheUni> gmaxwell: is this in theory? or are there documented cases of such fixes/splits?
 996 2013-07-22 20:01:25 <petertodd> TheUni: Both, and even if there were no cases, that'd just mean we had been doing our job.
 997 2013-07-22 20:01:29 <gmaxwell> TheUni: yes, we've created them ourselves in our own code.  Prior fixes in leveldb before we picked it up had this kind of potential too.
 998 2013-07-22 20:01:39 realzies has joined
 999 2013-07-22 20:01:49 nonick has quit (Remote host closed the connection)
1000 2013-07-22 20:01:57 <TheUni> gmaxwell: then imo rename it from leveldb. If leveldb can never be dropped in, then it's functionally a different lib for all future points
1001 2013-07-22 20:01:58 realzies is now known as Guest53978
1002 2013-07-22 20:02:01 <petertodd> TheUni: Consensus is just such a different problem than what normal software engineering faces.
1003 2013-07-22 20:02:05 <petertodd> TheUni: Good idea!
1004 2013-07-22 20:02:08 <gmaxwell> TheUni: None of our dependences promise to keep bugs. Sooo...
1005 2013-07-22 20:02:19 <TheUni> a rename in the srctree would discourage packagers from trying to drop it in.
1006 2013-07-22 20:02:26 nonick has joined
1007 2013-07-22 20:02:33 <gwillen> that's a really good idea
1008 2013-07-22 20:02:37 <gwillen> fork it and rename the fork bitcoindb
1009 2013-07-22 20:02:42 <gmaxwell> TheUni: we do update our leveldb from time to time, but we review and test the changes and gain a degree of confidence that a fork is unlikely.
1010 2013-07-22 20:02:45 <gwillen> and make some random irrelevant changes
1011 2013-07-22 20:02:54 <gwillen> just to prevent someone from being clever ;-)
1012 2013-07-22 20:03:17 <gmaxwell> But obviously a distro level-db package has no reason to go through that kind of review. Fixing a bug is usually a great thing. :)
1013 2013-07-22 20:03:40 <Luke-Jr> gmaxwell: that's a distro-specific thing
1014 2013-07-22 20:03:42 * petertodd wonders how many lines of usermode sourcecode bitcoin depends on
1015 2013-07-22 20:04:02 <gmaxwell> petertodd: it's also the case that not all of our depenencies are network critical.
1016 2013-07-22 20:04:15 <gmaxwell> (at least assuming 0-3 sigma bugs)
1017 2013-07-22 20:04:34 <gmaxwell> e.g. via qt we link zlib, but you're not going to fork the network with zlib changes with any great likelyhood.
1018 2013-07-22 20:04:35 <TheUni> gmaxwell: yea, the situation makes sense from both sides. But I also see how the distro guys see it as their job to bring those two sides together. So forcing an incompatibility the reasonable fix imo
1019 2013-07-22 20:04:36 <Luke-Jr> Gentoo's bitcoind depends on the exact LevelDB version with the exact configuration we use (ie, no snappy support)
1020 2013-07-22 20:05:02 <TheUni> eg, rename the lib, call it 1.0.0, and add a routine that bitcoind depends on
1021 2013-07-22 20:05:12 <Luke-Jr> TheUni: that's dumb
1022 2013-07-22 20:05:16 <gwillen> Luke-Jr: it's smart
1023 2013-07-22 20:05:18 <gmaxwell> TheUni: Agreed, as I said, I'm sympathic of the distro's motivations.  One challenge is that getting the distros to understand that we understand and aren't just being an ordinary obnoxious upstream is a problem.
1024 2013-07-22 20:05:24 <gwillen> Luke-Jr: it's also dumb, but that doesn't mean it's not smart
1025 2013-07-22 20:05:31 <Luke-Jr> TheUni: linking to system leveldb is a good thing, we just need to make sure anyone doing it has a clue
1026 2013-07-22 20:05:34 coeus has joined
1027 2013-07-22 20:05:42 <gmaxwell> TheUni: I've seen distros do a lot of work to undo embedding like that though.
1028 2013-07-22 20:05:49 <gmaxwell> So if they don't understand what we're doing even that may not be enough.
1029 2013-07-22 20:05:49 <TheUni> Luke-Jr: going by the explanation given above, linking to system leveldb would never be desirable
1030 2013-07-22 20:05:51 <Luke-Jr> ie, configure should refuse to do it without jumping through hoops
1031 2013-07-22 20:05:59 <petertodd> gmaxwell: Indeed, although pretty much any dependency can be intentially make network crit.
1032 2013-07-22 20:05:59 <gwillen> gmaxwell: yeah, but you make the Right Thing easier than the wrong thing
1033 2013-07-22 20:06:03 <gwillen> gmaxwell: that doesn't make the wrogn thing impossible
1034 2013-07-22 20:06:04 <gmaxwell> Luke-Jr: basically only gentoo is going to do what we need there.
1035 2013-07-22 20:06:19 <gmaxwell> gwillen: they already have to patch it to break it out, so I dunno that 'easier' is enough.
1036 2013-07-22 20:06:33 <gmaxwell> petertodd: Yes thats why I said 0-3 sigma bugs.
1037 2013-07-22 20:06:42 <gwillen> gmaxwell: well, that plus you put specific instructions somewhere obvious, in a comment, explaining why they shouldn't fuck with it
1038 2013-07-22 20:06:45 <gwillen> AND you make a blog post
1039 2013-07-22 20:06:48 <gwillen> and you yell at them if they try
1040 2013-07-22 20:06:50 <gmaxwell> petertodd: zlib could be randomly overwriting memory in a way we depend on, but this is very very unlikely.
1041 2013-07-22 20:06:51 <gwillen> defense in depth :-)
1042 2013-07-22 20:06:55 <TheUni> gmaxwell: would it be possible to detect such splits in-code. Meaning, have a set of black-listed db entires like some of the blacklisted bitcoin txns?
1043 2013-07-22 20:06:59 <gmaxwell> gwillen: I guess it's good now that debian is actually failing.
1044 2013-07-22 20:07:09 <Luke-Jr> TheUni: only if we know about them!
1045 2013-07-22 20:07:19 <TheUni> if such an entry is detected, shut down with an error that an incompat vers was detected
1046 2013-07-22 20:07:24 <gmaxwell> TheUni: only if you can anticipate all possible failures in advance. We could and should have a bit more sanity checking...
1047 2013-07-22 20:07:33 <gwillen> gmaxwell: I am asking a friend of mine who's part of debian what he would suggest
1048 2013-07-22 20:07:36 <Luke-Jr> gmaxwell: has anyone checked that Debian hasn't setup a procedure where leveldb is never updated without a review for this?
1049 2013-07-22 20:07:39 <TheUni> Luke-Jr: sure, but my point is that an upstream build could be detected against an in-tree one that way
1050 2013-07-22 20:07:39 <gmaxwell> But we already have some and it's not sufficient. There is a startup time trade off too.
1051 2013-07-22 20:07:44 <TheUni> regardless of future changes
1052 2013-07-22 20:07:58 <gmaxwell> Luke-Jr: are we the only leveldb use in gentoo?
1053 2013-07-22 20:08:14 <Luke-Jr> gmaxwell: doubtful
1054 2013-07-22 20:08:32 <gmaxwell> at least when we started down the leveldb route I didn't find anything else packaged that used it.
1055 2013-07-22 20:08:39 theo` has joined
1056 2013-07-22 20:08:50 <gmaxwell> I had hoped that would at least defer the packaging problems.
1057 2013-07-22 20:09:16 <gmaxwell> In any case, does anyone have a debian sid install? handy that can do some testing?
1058 2013-07-22 20:09:41 <gmaxwell> I still don't know _why_ it's rejecting the chain other than it's something in a april 2013 block and it rejects it during an initial sync.
1059 2013-07-22 20:09:41 <TheUni> gmaxwell: does it not take care of itself socially (assuming a non majority of debian users, that is) ?
1060 2013-07-22 20:09:54 <gmaxwell> (e.g. we're very fortunate to have dodged a bullet with something that was already in the chain)
1061 2013-07-22 20:10:32 <gmaxwell> TheUni: kinda, but anyone on the fork gets robbed. If there is almost noone using debian then obvious "too bad for you, using a weirdo distro build" ... but the ecosystem harm grows if there are more users.
1062 2013-07-22 20:10:46 <gmaxwell> (to be clear: has the potential of getting robbed if an attacker notices the fork)
1063 2013-07-22 20:10:46 <TheUni> gmaxwell: that's pretty much what i meant...
1064 2013-07-22 20:10:57 <TheUni> socially, that debian maintainer will be hanged eventually
1065 2013-07-22 20:11:24 <gmaxwell> TheUni: unless it gets to be too many nodes before the problem is noticed.
1066 2013-07-22 20:11:36 <Luke-Jr> can't TD get upstream to check for these things? ;)
1067 2013-07-22 20:11:38 theo__ has quit (Ping timeout: 240 seconds)
1068 2013-07-22 20:11:38 barmstrong has quit (Quit: barmstrong)
1069 2013-07-22 20:11:44 <gmaxwell> And then the black mark is on bitcoin.
1070 2013-07-22 20:11:47 <TD> hm?
1071 2013-07-22 20:12:03 MobiusL has quit (Ping timeout: 240 seconds)
1072 2013-07-22 20:12:05 <gmaxwell> Luke-Jr: We could try talking to the leveldb maintainers about what we need from them, I don't believe we have... but it's really asking a lot.
1073 2013-07-22 20:12:08 imton has quit (Quit: imton)
1074 2013-07-22 20:12:13 <Luke-Jr> TD: can you get upstream LevelDB to include "doesn't change behaviour at all, even bug fixes" in their process?
1075 2013-07-22 20:12:18 <TheUni> gmaxwell: other route would be to have a tm policy in place
1076 2013-07-22 20:12:26 <TheUni> i've gone down that route before with some other floss software
1077 2013-07-22 20:12:32 <TheUni> worth doing if the foundation hasn't done it yet
1078 2013-07-22 20:12:43 <gmaxwell> Foundation doesn't hold the mark, MtGOX does.
1079 2013-07-22 20:12:45 <petertodd> TheUni: tm policy?
1080 2013-07-22 20:12:46 <gmaxwell> AFAIK.
1081 2013-07-22 20:12:52 <TD> the behaviour isn't supposed to ever change
1082 2013-07-22 20:13:00 <TheUni> ah, that's a problem indeed :\
1083 2013-07-22 20:13:00 * Luke-Jr would oppose any kind of implementation-oppressive ™ policy. <.<
1084 2013-07-22 20:13:01 <TD> except for fixing serious bugs, of course. did it change?
1085 2013-07-22 20:13:17 <Luke-Jr> TD: the point is that fixing serious bugs changing behaviour IS BAD :p
1086 2013-07-22 20:13:23 <TheUni> Luke-Jr: it's not oppressive at all.
1087 2013-07-22 20:13:33 <gmaxwell> td: its changed in the past, IIRC there was a bug before where it would run out of FDs and return keys not found.
1088 2013-07-22 20:13:34 barmstrong has joined
1089 2013-07-22 20:13:35 <TD> well, it's not supposed to ever happen. AFAIK since we switched to leveldb there were no such changes
1090 2013-07-22 20:13:36 <Luke-Jr> TheUni: yes it is.
1091 2013-07-22 20:13:39 MobiusL has joined
1092 2013-07-22 20:13:46 <gmaxwell> (in the past meaning before we switched to it)
1093 2013-07-22 20:13:49 <TD> well, yes. that was fixed.
1094 2013-07-22 20:13:49 <TheUni> Luke-Jr: you find mozilla's policy oppressive?
1095 2013-07-22 20:13:52 <Luke-Jr> TheUni: yes.
1096 2013-07-22 20:13:59 <Luke-Jr> TheUni: also, not the same thing.
1097 2013-07-22 20:14:06 <TD> i mean technically any bug can be behaviour. that's one reason we embed it, so we can carefully review the diffs and make a case by case decision
1098 2013-07-22 20:14:12 <Luke-Jr> TheUni: Mozilla isn't using a trademark of "World Wide Web", they're using a brand.
1099 2013-07-22 20:14:23 <gmaxwell> td: some background, debian is shipping a copy of bitcoin relinked to system libs. It rejects the chain in an april 2013 block, though we don't know why yet.
1100 2013-07-22 20:14:37 <Luke-Jr> TD: can we get upstream to make sure it never changes, even for bugfixes, without a clear prominent disclosure?
1101 2013-07-22 20:14:41 <TD> a system leveldb?
1102 2013-07-22 20:14:44 <gmaxwell> TD: fortunately since it rejects in the past this isn't a sev 0 security problem.
1103 2013-07-22 20:14:47 <gmaxwell> TD: yes.
1104 2013-07-22 20:14:57 ThomasV has joined
1105 2013-07-22 20:15:06 <TheUni> Luke-Jr: correct. in this case, bitcoind is the brand. not bitcoin.
1106 2013-07-22 20:15:24 <TD> well, everyone knows linux packaging is a fucking disaster zone. i spent several years trying to make that community change their ways and they never did. we should just detect linux useragents with a bit of javascript on bitcoin.org and have a big flashing warning telling people not to use distributor packaging
1107 2013-07-22 20:15:24 <gmaxwell> "icecoin"
1108 2013-07-22 20:15:27 <TheUni> Luke-Jr: if you run a modified firefox, it's not firefox. see iceweasel et all
1109 2013-07-22 20:15:27 <Luke-Jr> TheUni: oh ok, I thought you meant abusing the Bitcoin trademark
1110 2013-07-22 20:15:37 <Luke-Jr> TheUni: my modified Firefox says Firefox ;)
1111 2013-07-22 20:15:41 <TheUni> *et al
1112 2013-07-22 20:15:54 <petertodd> Luke-Jr: I'd be OK with a "tm" policy *if* Bitcoin had a core library for validation and block processing, everything else is nowhere near as consensus critical. You'd basically be able to say "luke-jr bitcoin, based on Bitcoin Core(TM)"
1113 2013-07-22 20:16:00 <TD> what we could also do is make some custom changes to leveldb (change some API prototypes) so a standard leveldb won't work
1114 2013-07-22 20:16:00 <Luke-Jr> TD: that's nonsense.
1115 2013-07-22 20:16:02 <gwillen> gmaxwell: by what means was debian asked not to package it? Is there a public request somewhere?
1116 2013-07-22 20:16:08 <TD> (unless they also patch the code that uses it, etc
1117 2013-07-22 20:16:09 <Luke-Jr> Linux packaging is lightyears ahead of everything else.
1118 2013-07-22 20:16:19 <gmaxwell> TD: that was gwillen and TheUni's suggestion. Of course, they're already patching to use the system one.
1119 2013-07-22 20:16:21 <gwillen> gmaxwell: I'm told that debian is somewhat anarchic, but there are people who can fulfill such a request, if they see it
1120 2013-07-22 20:16:34 <TD> as someone familiar with the software distribution schemes of many OS's i can assure you, linux is by far the worst
1121 2013-07-22 20:16:34 <Luke-Jr> petertodd: I wouldn't; someone should be free to implement Bitcoin using their own unrelated code
1122 2013-07-22 20:16:51 <TD> gmaxwell: remote attestation ;)
1123 2013-07-22 20:16:56 sserrano44 has quit (Quit: Computer has gone to sleep.)
1124 2013-07-22 20:17:02 <TD> no, i jest. i think a big flashing warning on the home page is the way to go
1125 2013-07-22 20:17:12 <petertodd> Luke-Jr: Nothing stopping them, they just can't use the magic words "Bitcoin Verification Core(TM)"
1126 2013-07-22 20:17:18 <TheUni> Luke-Jr: they could do whatever they wanted, they just couldn't call it bitcoind
1127 2013-07-22 20:17:21 <TD> asking linux distributors not to package things won't work. they will just ignore us. i know because i've been in this situation before.
1128 2013-07-22 20:17:22 <TheUni> ^^
1129 2013-07-22 20:17:28 <petertodd> Luke-Jr: heck, call it "Bitcoin Foundation Verification Core(TM)" to be really clear
1130 2013-07-22 20:17:37 <gwillen> TD: well, I have a Debian Developer asking me for more information
1131 2013-07-22 20:17:51 <gwillen> TD: so if we actually want them to not package it, I want to give that person more information, and see what happens
1132 2013-07-22 20:17:51 <TD> what information does he need? tell him to delete his packages and send users upstream to get binaries
1133 2013-07-22 20:17:51 jedunnigan has joined
1134 2013-07-22 20:17:51 <gmaxwell> Okay, so I think a two fold approach makes sense right now:  (1) better info to cluestick people, (2) a nice blog post on why this is an unusual concern for bitcoin.
1135 2013-07-22 20:17:52 <Luke-Jr> petertodd: it begs to be made irrelevant ;)
1136 2013-07-22 20:18:21 <gwillen> TD: he wants me to point him to the request from the actual bitcoin devs
1137 2013-07-22 20:18:23 <gwillen> TD: which I am not one of
1138 2013-07-22 20:18:31 <TD> i can do a post to the bitcoin forum
1139 2013-07-22 20:18:31 <gwillen> TD: that's why I'm asking how it was made, and whether it was published
1140 2013-07-22 20:18:38 <Luke-Jr> FWIW, I agree that given Debian's packaging model (needing a new package name for different versions/builds), embedding it is the right solution for them
1141 2013-07-22 20:18:41 <TheUni> gmaxwell: do you know if the foundation has discussed such an agreement? I've worked with the SFLC on exactly that, i'd be curious to hear the current status/opinion
1142 2013-07-22 20:18:44 <gmaxwell> In the long term there should probably be some certified behavior mark.  "Certified by Bluematt(tm)"
1143 2013-07-22 20:18:49 <TD> heh
1144 2013-07-22 20:18:49 <Diablo-D3> http://boingboing.net/2013/07/22/bhangra-remix-of-daft-punks.html
1145 2013-07-22 20:18:57 <petertodd> Luke-Jr: No, if your core validation library is sufficiently small, it will be the part that you can't change anyway without risking forks.
1146 2013-07-22 20:19:34 <TD> gwillen: it's common sense, it shouldn't really require a special request. but would it help if i sum up the problems in a public forum post?
1147 2013-07-22 20:19:37 <gmaxwell> Then there is an interesting question if nodes transmit "Certified by Bluematt(tm)" over the p2p port, and if peers won't treat non-"Certified by Bluematt(tm)" as full nodes. :P
1148 2013-07-22 20:19:50 <gmaxwell> (interesting software freedom question)
1149 2013-07-22 20:19:55 <gwillen> TD: I don't want common sense, I want an Official Request from Someone Official
1150 2013-07-22 20:20:04 <gwillen> those work much better
1151 2013-07-22 20:20:20 <Luke-Jr> TD: it's not common sense, it's a special situation
1152 2013-07-22 20:20:28 paraipan has quit (Quit: Saliendo)
1153 2013-07-22 20:20:29 <TheUni> gmaxwell: indeed. Imo it'd be up to the protocol to sort that out via rules rather than client detection
1154 2013-07-22 20:20:39 <Luke-Jr> for every other software package, the request to embed libraries is unreasonable.
1155 2013-07-22 20:20:43 <TheUni> otherwise you get into nasty territory (see web browsers)
1156 2013-07-22 20:20:43 <petertodd> gmaxwell: Which would actually be really bad, because non-satoshi peers are a good thing re: making sure relay bugs don't cause problems.
1157 2013-07-22 20:20:51 sserrano44 has joined
1158 2013-07-22 20:20:52 <Luke-Jr> gwillen: Bitcoin has no official.
1159 2013-07-22 20:21:06 <gmaxwell> I agree that it's special. I've been irritated by my packagers before, but on other projects I've never thought that "remove the program" would be a better solution, but here that doesn't sound unreasonable to me.
1160 2013-07-22 20:21:11 <gwillen> Luke-Jr: I understand, but gmaxwell is telling me that A Request was made for debian not to package it
1161 2013-07-22 20:21:20 <petertodd> gmaxwell: Provided a peer isn't DoSing you and you have a path to majority hashing power, who cares what they are running?
1162 2013-07-22 20:21:24 <TD> it's not really. we've seen similar critical bugs introducing during packaging in openssl, wine and firefox, to give a few notorious examples.
1163 2013-07-22 20:21:27 <gwillen> and it appears that the request did not go to the right party
1164 2013-07-22 20:21:28 <gmaxwell> Luke-Jr: I already, as an upstream, suggested debian not package it.
1165 2013-07-22 20:21:35 <gwillen> gmaxwell: who did you suggest it to, and how?
1166 2013-07-22 20:21:38 <Luke-Jr> gmaxwell: gwillen wants the link :P
1167 2013-07-22 20:22:04 <Luke-Jr> TD: not similar, no
1168 2013-07-22 20:22:16 <gwillen> gmaxwell: e.g. there is http://lists.alioth.debian.org/pipermail/pkg-bitcoin-devel/ , which is the Official List for this package, it appears
1169 2013-07-22 20:22:38 <gmaxwell> gwillen: On IRC to one of the people that was supposted to be maintaining it and said that they should probably remove it, because version consistency is important and doesn't really match debian's release cycle.
1170 2013-07-22 20:22:49 <gwillen> ah, I see
1171 2013-07-22 20:22:55 <Luke-Jr> someone should write up a draft Formal Request of some sort, which we can all edit, and then everyone sign off
1172 2013-07-22 20:23:02 <Luke-Jr> lots of names is good
1173 2013-07-22 20:23:02 <gwillen> so there was never anything that rose to the level of an Official Request
1174 2013-07-22 20:23:12 <petertodd> Hmm... a foundation blog post should also include a user-oriented "DO NOT use distro-packaged bitcoind/bitcoin-qt"
1175 2013-07-22 20:23:21 <gwillen> gmaxwell: did anybody actually talk to them about like, not screwing with it?
1176 2013-07-22 20:23:22 <nsh> gmaxwell, is it currently possible to using Bitcoin to have a decryption key released at a certain time in the future (as measured by blocks, for instance) in a demonstrable manner?
1177 2013-07-22 20:23:25 <Luke-Jr> petertodd: but that's wrong too
1178 2013-07-22 20:23:27 <gmaxwell> I suppose not!  Sorry, I'm used to working with the maintainer of my xiph.org packages and he is 100% IRC API.
1179 2013-07-22 20:23:29 <gwillen> gmaxwell: or just the one offhand comment that they shouldn't package it?
1180 2013-07-22 20:23:40 <TheUni> petertodd: s/don't use distro/don't use unverified binaries/g
1181 2013-07-22 20:23:43 <petertodd> Along with some explanation of the gitian process and how to verify you have the real thing.
1182 2013-07-22 20:23:58 <gwillen> gmaxwell: because a request not to screw with it would probably be a good idea, if nobody's actually requested that of them yet
1183 2013-07-22 20:24:02 <Luke-Jr> petertodd: gitian process does not work for Linux really. it makes Ubuntu binaries.
1184 2013-07-22 20:24:06 <gwillen> gmaxwell: before a big announcement behind their backs asking people not to use their package
1185 2013-07-22 20:24:09 <gmaxwell> petertodd: too bad gitian needs so much state, I'd love to try to get the distros to gitian too. :P
1186 2013-07-22 20:24:16 <Luke-Jr> petertodd: and it's no more secure than distros in that sense
1187 2013-07-22 20:24:38 <Luke-Jr> why should users trust Ubuntu rather than their own distro?
1188 2013-07-22 20:24:47 <petertodd> gmaxwell: Yeah, if they *were* using gitian, we could give totally different advice.
1189 2013-07-22 20:24:49 <Luke-Jr> at least trusting their own distro is distributed
1190 2013-07-22 20:24:53 <gmaxwell> gwillen: I always think it's best to give people heads up regardless.
1191 2013-07-22 20:25:00 <gwillen> gmaxwell: *nods*
1192 2013-07-22 20:25:06 <gmaxwell> Even if we're going to flame them, we should send them a prerelease draft.
1193 2013-07-22 20:25:20 <gwillen> gmaxwell: but if nobody's tried just like, asking them to leave the baked-in leveldb
1194 2013-07-22 20:25:21 <gmaxwell> make sure the public argument is about the stuff where there is disagreement.
1195 2013-07-22 20:25:25 <gwillen> gmaxwell: and to reverse whatever else might be an issue
1196 2013-07-22 20:25:27 <petertodd> Luke-Jr: Trusting a distro you make yourself is also impractical advice for most people.
1197 2013-07-22 20:25:29 <gwillen> someone shold probably try that first
1198 2013-07-22 20:26:07 <TheUni> gmaxwell: seems to me there's nothing debian-specific about this issue. It could be a calmly worded open-letter to distros
1199 2013-07-22 20:26:13 <TheUni> otherwise the flame-gates open up
1200 2013-07-22 20:26:27 <petertodd> TheUni: good point, debian's just the first
1201 2013-07-22 20:26:31 <TheUni> (other than the fact that it's debian in this case, that is)
1202 2013-07-22 20:26:43 <Luke-Jr> petertodd: masses trusting N different distros is better than masses trusting 1 specific distro
1203 2013-07-22 20:27:25 <TD> i'm writing up something in a google doc that we could potentially sign
1204 2013-07-22 20:27:25 <petertodd> Luke-Jr: Depends on the threat, for consensus it's worse, for wallet security it's better.
1205 2013-07-22 20:27:33 <Luke-Jr> TD: bah, I just started the same!
1206 2013-07-22 20:27:39 <TD> :)
1207 2013-07-22 20:27:47 <Luke-Jr> TD: share yours for others to view/edit? :p
1208 2013-07-22 20:27:58 <petertodd> ...well if there are two google docs it points out the distributed nation of bitcoin...
1209 2013-07-22 20:28:02 * petertodd ducks
1210 2013-07-22 20:28:02 <TD> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit?usp=sharing
1211 2013-07-22 20:29:16 <petertodd> heh, watching TD type reminds me of my BBS days...
1212 2013-07-22 20:29:52 <TD> i wonder what's up with the animals
1213 2013-07-22 20:29:54 <Luke-Jr> TD: yours reads very centralized so far :p
1214 2013-07-22 20:30:01 <TD> i guess "anonymous user" was too boring...
1215 2013-07-22 20:30:31 <petertodd> s/unbundled/replaced with shared libraries/ ?
1216 2013-07-22 20:30:37 Application has joined
1217 2013-07-22 20:30:43 <gmaxwell> We still need to figure out whats actually breaking in debian now.
1218 2013-07-22 20:30:45 <Luke-Jr> "We have seen a version of Bitcoin modified during the Debian distribution process exit the consensus for reasons that are unclear" we have?
1219 2013-07-22 20:30:52 <gmaxwell> Being able to point out a _real_ problem will help make it persusaive.
1220 2013-07-22 20:31:05 <TD> i think that's just what was stated
1221 2013-07-22 20:31:11 <TD> the debian bitcoin failed to process an april block
1222 2013-07-22 20:31:15 <TD> but i don't know what diffs are applied
1223 2013-07-22 20:31:43 <petertodd> TD: that you don't know is IMO worth mentioning to make it clear how fragile the consensus is
1224 2013-07-22 20:31:50 <TD> http://ftp-master.metadata.debian.org/changelogs//main/b/bitcoin/bitcoin_0.8.3-1_changelog
1225 2013-07-22 20:32:12 mappum has joined
1226 2013-07-22 20:32:28 <gmaxwell> http://sources.debian.net/src/bitcoin/0.8.3-1/debian/patches here are the patches.
1227 2013-07-22 20:32:39 sserrano44 has quit (Quit: Computer has gone to sleep.)
1228 2013-07-22 20:32:45 ProfMac has quit (Ping timeout: 250 seconds)
1229 2013-07-22 20:33:16 zariok_ has left ()
1230 2013-07-22 20:33:51 Applicat_ has quit (Ping timeout: 248 seconds)
1231 2013-07-22 20:34:14 <TD> they all look pretty innocuous except for the system leveldb
1232 2013-07-22 20:34:17 <Luke-Jr> TD: IMO, I would approach this as a "how to use system/packaged leveldb with Bitcoin-Qt" and have the text lead to the conclusion that it's too much effort and the easy route or Just Don't Do It is best <.<
1233 2013-07-22 20:34:22 ThomasV has quit (Read error: Connection reset by peer)
1234 2013-07-22 20:34:26 <petertodd> 1007_libmemenv_hurd.patch <- interesting, a patch to the leveldb even though they change it to use the leveldb
1235 2013-07-22 20:35:00 jgarzik has joined
1236 2013-07-22 20:35:02 <petertodd> Luke-Jr: strongly disagree, leveldb is consensus critical
1237 2013-07-22 20:35:29 <petertodd> 2002_libmemenv_debian-ports.patch <- second leveldb patch
1238 2013-07-22 20:35:36 <gmaxwell> It's important to note that leveldb isn't the only consensus critcial code we have. I think that it's some of the _riskiest_ consensus critcial code however.
1239 2013-07-22 20:35:48 <jgarzik> leveldb consensus is indeed critical -- we have already had fork risk related to database libraries
1240 2013-07-22 20:35:56 <jgarzik> let's not reinvent old, solved problems
1241 2013-07-22 20:36:08 <gmaxwell> OpenSSL and boost are every bit as critical, but also less likely to change in a way that doesn't fail instantly or fail our unit tests.
1242 2013-07-22 20:36:10 <Luke-Jr> petertodd: that's my point
1243 2013-07-22 20:36:36 <petertodd> Luke-Jr: and my point is it's damn dangerous, so just don't do it
1244 2013-07-22 20:37:06 Guest53978 has quit (Read error: Connection reset by peer)
1245 2013-07-22 20:37:07 <gmaxwell> petertodd: I don't think you and luke arguing is likely to be productive here.
1246 2013-07-22 20:37:09 <TD> anyone want to comment on the doc?
1247 2013-07-22 20:37:12 <TD> or sign it?
1248 2013-07-22 20:37:14 <petertodd> reminds me: Partial UTXO mode will trigger more leveldb failures because you'll see more nodes with different amounts of data in the database.
1249 2013-07-22 20:37:23 <gmaxwell> TD: where is it?
1250 2013-07-22 20:37:24 <petertodd> gmaxwell: good point
1251 2013-07-22 20:37:25 <TD> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit
1252 2013-07-22 20:37:39 <gmaxwell> petertodd: luke is doing something in gentoo which I think is adequately safe, but I don't think anyone else will do it.
1253 2013-07-22 20:37:41 <Luke-Jr> TD: I already commented.
1254 2013-07-22 20:38:04 <Luke-Jr> TD: IMO, I would approach this as a "how to use system/packaged leveldb with Bitcoin-Qt" and have the text lead to the conclusion that it's too much effort and the easy route or Just Don't Do It is best <.<
1255 2013-07-22 20:38:06 <petertodd> gmaxwell: interesting
1256 2013-07-22 20:38:20 <TD> well, i'm not sure that gets across the strength of concern. but ok, noted.
1257 2013-07-22 20:38:29 <Luke-Jr> educate them on what's involved/necessary, and lead them to come to the conclusion
1258 2013-07-22 20:38:55 <Luke-Jr> side effect: we may get people who really want to do it enough, that they contribute to LevelDB update reviews
1259 2013-07-22 20:38:56 <petertodd> Luke-Jr: given it should be a short FYI warning, maybe add a link to contact you about how to do it right?
1260 2013-07-22 20:38:59 <gmaxwell> petertodd: gentoo's package management is flexible enough to express "must be linked with this version _Exactly_"
1261 2013-07-22 20:39:15 <Luke-Jr> petertodd: well, I was thinking of more of a longer document, but maybe
1262 2013-07-22 20:39:16 <petertodd> gmaxwell: that changes the situation a lot
1263 2013-07-22 20:39:33 <gmaxwell> petertodd: and with the right kicking can happily handle having multiple versions installed.
1264 2013-07-22 20:39:36 <petertodd> Luke-Jr: or write it as an appendix? I'm thinking we want to get the point across in the first page (above the fold)
1265 2013-07-22 20:39:49 ProfMac has joined
1266 2013-07-22 20:39:51 <Luke-Jr> I suppose a shorter document can always be elaborated on later
1267 2013-07-22 20:40:30 avyd has quit (Quit: Leaving)
1268 2013-07-22 20:41:12 <gmaxwell> Before sending this we should get a better understanding of why the debian copy is failing.
1269 2013-07-22 20:41:20 <TD> does anyone have a log?
1270 2013-07-22 20:41:26 <Luke-Jr> erm "a request from the upstream maintainers to not distribute Bitcoin as part of distribution package repositories."
1271 2013-07-22 20:41:30 <jgarzik> TD, a doc being edited by luke-jr and petertodd in parallel?  I'll wait a bit to sign :) :)
1272 2013-07-22 20:41:36 <TD> haha
1273 2013-07-22 20:41:37 <gmaxwell> It would look a little silly to implicated leveldb and have it turn out to be GCC or something... though it doesn't really change our message.
1274 2013-07-22 20:41:41 <Luke-Jr> packaging bitcoin clients should be expected. just not modifying them.
1275 2013-07-22 20:42:02 <petertodd> jgarzik: lol
1276 2013-07-22 20:42:11 <TD> i think the temptation will prove too much. besides, you lose the nice auditability of deterministic binaries
1277 2013-07-22 20:42:44 <gmaxwell> we might want a note about determinstic binaries in this.
1278 2013-07-22 20:42:52 <TD> there's one at the end
1279 2013-07-22 20:42:54 <TD> last sentence
1280 2013-07-22 20:43:02 <gmaxwell> haha.
1281 2013-07-22 20:43:05 <gmaxwell> sorry!
1282 2013-07-22 20:43:19 <gmaxwell> petertodd: careful on length.
1283 2013-07-22 20:43:24 <TD> the other problem with distributor packaging is that they will attempt to backport security fixes
1284 2013-07-22 20:43:35 <Luke-Jr> telling distros not to distribute clients at all is ridiculous. I'd sign against it. :/
1285 2013-07-22 20:43:41 <jgarzik> I thought about the doc.  My idea for table of contents (doc sections):  1) describe why system lib inclusion is a good thing in general.  use zlib as example.   2) describe fork risk.  include description of recent hard fork event, and note how database lib played a role.  3) packager recommendations.  short, and specific.  "do not elide leveldb; be careful with openssl"
1286 2013-07-22 20:43:49 <Luke-Jr> TD: well, that's why we have backport branches
1287 2013-07-22 20:43:49 <TD> or - they'll get frozen on a single version that might get hardforked off, etc. just generally asking them to ignore all their existing policies for this package won't work reliably, i think
1288 2013-07-22 20:43:54 <jgarzik> do not delve too far into other details
1289 2013-07-22 20:43:57 <petertodd> Luke-Jr: Can we agree on the please don't until you talk to us?
1290 2013-07-22 20:43:57 <jgarzik> short and sweet
1291 2013-07-22 20:44:00 <gmaxwell> Luke-Jr: would you agree with something like "don't distribute unless you are able to deal with this"
1292 2013-07-22 20:44:08 <gmaxwell> Luke-Jr: like what petertodd said.
1293 2013-07-22 20:44:16 <jgarzik> petertodd, +1
1294 2013-07-22 20:44:21 <Luke-Jr> jgarzik: +1
1295 2013-07-22 20:44:36 <gmaxwell> jgarzik: I like describing why it is important. Show that we do understand the motivations.
1296 2013-07-22 20:44:43 <gmaxwell> We care about them too.
1297 2013-07-22 20:44:47 <Luke-Jr> gmaxwell: I don't see harm in distributing it unmodified, at least.
1298 2013-07-22 20:44:51 <jgarzik> gmaxwell, that's section #1
1299 2013-07-22 20:44:56 wiretapped has quit (Remote host closed the connection)
1300 2013-07-22 20:44:59 <jgarzik> gmaxwell, show them we understand the general principle
1301 2013-07-22 20:45:10 <jgarzik> gmaxwell, section #2, describe why we deviate from general principle
1302 2013-07-22 20:45:23 <jgarzik> gmaxwell, section #3, specific technical recommendations
1303 2013-07-22 20:45:24 <Luke-Jr> petertodd: I think encouraging anyone making modifications *in general* to talk to us before public releases, is a good idea.
1304 2013-07-22 20:45:32 serialbandicoot has quit (Quit: serialbandicoot)
1305 2013-07-22 20:45:33 <petertodd> Luke-Jr: agreed
1306 2013-07-22 20:45:35 <jgarzik> section #3 should be very short, very direct
1307 2013-07-22 20:45:41 <Luke-Jr> with emphasis on script/blockchain related code
1308 2013-07-22 20:46:13 <gmaxwell> I'd add do the recommendations is that we provide an open offer to consult with them. Lets get people talking. It's sad that we're not even aware of the crazy stuff people are doing until we get reports.
1309 2013-07-22 20:46:19 <TD> i think "don't distribute it" is pretty short and direct :)
1310 2013-07-22 20:46:25 <Luke-Jr> TD: and wrong
1311 2013-07-22 20:46:25 <gmaxwell> There is someone competent on this matter in this channel 24/7.
1312 2013-07-22 20:46:44 <gmaxwell> TD: it may be too much to ask for and also too much like what someone who is clueless about this stuff demands.
1313 2013-07-22 20:46:48 <TD> not being aware of dumb distributor patches is pretty normal. i wasted too many hours debugging bugs introduced by "helpful" packaging back when i worked on wine.
1314 2013-07-22 20:47:07 <TD> a marathon debugging session often ended up with the discovery of a surprising patch some unknown guy had silently applied
1315 2013-07-22 20:47:08 <petertodd> I think we can remove the last line IMO
1316 2013-07-22 20:47:19 <Luke-Jr> TD: that's patching, not distributing.
1317 2013-07-22 20:47:26 sserrano44 has joined
1318 2013-07-22 20:47:37 <TD> well, i know your packages may be an exception, but normally they go hand in hand
1319 2013-07-22 20:47:41 <gmaxwell> petertodd: I do think it's good to mention that our normal model has this property that distro packages lack.
1320 2013-07-22 20:47:56 <TD> they always find some reason why some change seems harmless
1321 2013-07-22 20:48:10 <TD> like the openssl change they thought was a no-op
1322 2013-07-22 20:48:21 ProfMac has quit (Ping timeout: 250 seconds)
1323 2013-07-22 20:48:28 BurtyBB has joined
1324 2013-07-22 20:48:38 <sipa> gmaxwell, TD, TheUni: regarding leveldb changes - since some 0.8.x change, we detect database errors as separate from validation errors, so they should just cause a quit (which is perhaps a DoS attack), but it doesn't have chain splitting risk
1325 2013-07-22 20:48:46 <petertodd> gmaxwell: good point
1326 2013-07-22 20:49:01 <TD> cool
1327 2013-07-22 20:49:23 <sipa> and if any leveldb doesn't read back the data as it was written, that is a critical bug
1328 2013-07-22 20:49:27 <sipa> for leveldb i mean
1329 2013-07-22 20:49:35 ProfMac has joined
1330 2013-07-22 20:49:35 <TD> yeah. there have been critical bugs like that in the past though
1331 2013-07-22 20:49:49 <sipa> still, it cannot hurt that we follow up on the changes made upstream before adopting them
1332 2013-07-22 20:49:49 <TD> the refresh that vinnies pull request is waiting to do fixes one such bug, although bitcoin isn't affected by it
1333 2013-07-22 20:50:07 <TD> one can imagine though, that a "simple" change by some packager could have exposed us to it
1334 2013-07-22 20:50:23 <petertodd> sipa: but even leveldb being unusually slow for particular data can break consensus for us
1335 2013-07-22 20:50:39 <jgarzik> Please be aware of the distributor context, though!  Speaking as one who wandered the corridors of Fedora high level devs...  they wage a constant battle against this behavior.  Everybody loves to embed+ship libs, and there is a decade-long history of the practice creating security problems.  The general tenor of the message should be "we REALLY DO understand why packagers want to ship system libs, but trust us, we have a reason not to, and $h
1336 2013-07-22 20:50:39 <jgarzik> ere is why"
1337 2013-07-22 20:51:12 <jgarzik> Red Hat v. Google constantly fight over Chrome* lib shipping
1338 2013-07-22 20:51:15 <gmaxwell> jgarzik++
1339 2013-07-22 20:51:24 wathefak has joined
1340 2013-07-22 20:51:31 BurtyB has quit (Ping timeout: 248 seconds)
1341 2013-07-22 20:51:54 <gmaxwell> the debian packager for most of my codec stuff is also an upstream contributor now and hangs out in the channels and has lots of stories about REALLY STUPID upstreams.
1342 2013-07-22 20:51:55 <petertodd> jgarzik: say something like "In Bitcoin the requirements for consensus even outweight the usual desire to ship patches quickly."
1343 2013-07-22 20:52:13 * jgarzik handwaves, 90+% of the embedded lib shipping is wrong and hides bugs
1344 2013-07-22 20:52:17 Jasmin68k has quit (Quit: Leaving.)
1345 2013-07-22 20:52:23 <sipa> petertodd: note that we only use libmemenv for the unit tests
1346 2013-07-22 20:52:28 wiretapped has joined
1347 2013-07-22 20:52:38 <gmaxwell> jgarzik: or even if its right, it still hides bugs. :P
1348 2013-07-22 20:52:39 <Luke-Jr> jgarzik: I'd say 99+%!
1349 2013-07-22 20:53:15 <gmaxwell> Luke-Jr: some portion is merely harmless.
1350 2013-07-22 20:53:25 <gmaxwell> very little is actually good.
1351 2013-07-22 20:53:53 <Luke-Jr> gmaxwell: even if it's "harmless", it makes more work for distributors, so harmful in that sense <.<
1352 2013-07-22 20:54:44 <gmaxwell> perhaps balanced with upstream bug reporting load though.
1353 2013-07-22 20:54:48 <TD> jgarzik: given that chrome has literally pushed seamless auto updates into new realms, you'd think red hat would get over it and let them do what they wanted.
1354 2013-07-22 20:54:57 <petertodd> jgarzik: How's the text I added re: "consensus is a security issue"
1355 2013-07-22 20:55:24 <Luke-Jr> TD: Google can be as centralized as they want with their own software, but that's a big problem for things like Bitcoin.
1356 2013-07-22 20:55:40 <TD> if someone sees a "stupid upstream" the right fix is to do a fork and become a new upstream. not silently fork it behind peoples back at the packaging level
1357 2013-07-22 20:55:48 <TD> or contribute patches
1358 2013-07-22 20:56:08 <Luke-Jr> TD: embedding libraries (generally) makes one a stupid upstream, but generally not enough reason to fork
1359 2013-07-22 20:56:20 <Luke-Jr> packaging-independent auto-upgrade as well
1360 2013-07-22 20:56:32 <gmaxwell> TD: Agreed. And good distro packagers aren't silent.
1361 2013-07-22 20:58:18 <Luke-Jr> anyhow, I guess the topic is deviating a bit
1362 2013-07-22 20:58:26 <Luke-Jr> I suggest we go with jgarzik's outline
1363 2013-07-22 21:01:05 <petertodd> Luke-Jr, jgarzik: agreed, current document seems unfocused to me
1364 2013-07-22 21:01:25 <gwillen> btw, I would suggest not waiting until the bug is found to specifically contact debian about this
1365 2013-07-22 21:01:53 Prattler has quit (Quit: ZNC - http://znc.in)
1366 2013-07-22 21:01:55 <gwillen> just contact them and advise that 1) their version is incompatible, and 2) they're making some changes, at least one of which has caused a problem in the past, and could they back that one out and maybe also help with deubgging
1367 2013-07-22 21:02:08 <gwillen> and by (1) I mean point to the fact that it actually does not work, which is not speculation
1368 2013-07-22 21:02:50 <gmaxwell> gwillen: because it forks off early in the chain I do not believe this is as urgent as it might be otherwise.
1369 2013-07-22 21:02:58 <gwillen> gmaxwell: that's very fair
1370 2013-07-22 21:03:10 <gmaxwell> gwillen: If it were something not yet triggered in the chain I wouldn't be discussing it here.
1371 2013-07-22 21:03:13 <gwillen> gmaxwell: otoh that's a lot of potentially frustrated users
1372 2013-07-22 21:03:19 <gmaxwell> (because it would be an exploitable vulnerability)
1373 2013-07-22 21:03:22 * gwillen nod
1374 2013-07-22 21:03:33 <TheSeven> hm, looks like I just triggered some primecoin bug... I attempted to swipe several hundred txouts, with default fee settings, and while the resulting transaction is being relayed, it isn't being mined :/
1375 2013-07-22 21:03:47 <TheSeven> any general hints on how to fix that kind of mess?
1376 2013-07-22 21:04:39 <gmaxwell> TheSeven: salvagewallet your wallet (After a backup) and try again.
1377 2013-07-22 21:06:14 <TheSeven> gmaxwell: is there an easy (and fast) way to merge wallets? I just care about the keys, not the txn history etc.
1378 2013-07-22 21:06:42 <TheSeven> right now I usually extract the keys using pywallet and import them using RPC commands, but that's terribly slow
1379 2013-07-22 21:07:10 <gmaxwell> use the wallet recovery tool on a bunch of concatinated wallets.
1380 2013-07-22 21:07:19 <gmaxwell> doesn't work if they're encrypted.
1381 2013-07-22 21:07:32 <TheSeven> interesting approach
1382 2013-07-22 21:08:18 <TheSeven> I have ~170k privkeys to import, check for funds, swipe and discard from a huge primecoin farm
1383 2013-07-22 21:08:34 <TheSeven> takes almost a day through RPC...
1384 2013-07-22 21:09:22 <petertodd> jgarzik: How's the current version read? Seems pretty close to your outline.
1385 2013-07-22 21:10:22 idstam has quit ()
1386 2013-07-22 21:11:35 <Luke-Jr>  and memory usage?
1387 2013-07-22 21:12:15 <gmaxwell> petertodd: I'd like to be able to say something like we can help provide you with testing procedures to reduce risks...  or something because I do think its sounding a bit too much like its saying we're demanding you use the software exactly.
1388 2013-07-22 21:12:23 Gnaf has quit (Changing host)
1389 2013-07-22 21:12:23 Gnaf has joined
1390 2013-07-22 21:12:32 <gmaxwell> petertodd: which may gain us criticism from people who really don't completely grok the hardness of the consensus problem.
1391 2013-07-22 21:13:12 <gmaxwell> "Bitcoin is rubbish made by idiots who can't even write software secure enough to handle divergence in clients for their network protcol HAHA!"
1392 2013-07-22 21:13:24 <TheUni> it makes sense to me to remove the references to leveldb in the letter, and instead commit a set of packaging instructions in source
1393 2013-07-22 21:13:29 yubrew has quit (Remote host closed the connection)
1394 2013-07-22 21:13:32 <petertodd> gmaxwell: good points, though I'd rather they think bitcoin is rubbish than they ship broken clients
1395 2013-07-22 21:13:46 <TheUni> so that they may be updated in the future, and the current requirements are always bundled with a corresponding srctree
1396 2013-07-22 21:13:52 <gmaxwell> petertodd: keep in mind that 99.999% of people who will read this are not distro packaging people.
1397 2013-07-22 21:14:26 nonick has quit (Remote host closed the connection)
1398 2013-07-22 21:14:30 <TheUni> then reference those instuctions in the letter if necessary
1399 2013-07-22 21:14:38 nonick has joined
1400 2013-07-22 21:14:45 <TheUni> otherwise, this is a one-off post that fades away in time
1401 2013-07-22 21:15:03 <gmaxwell> I think TheUni has a good suggestion. The instructions can even be "DON'T" but saying in the document that we have instructions for you is an improvement.
1402 2013-07-22 21:16:01 <petertodd> TheUni: good point, so "DON'T UNLESS" is page one, "HOW" is page two
1403 2013-07-22 21:16:16 <Luke-Jr> "For this reason, it is vital that as much of the network as possible uses the upstream reference implementation unmodified in any way." screams centralization
1404 2013-07-22 21:16:20 <TheUni> it could even be added in the man pages, so that distros would have to either patch out the upstream requirements, or violate the requirements listed in 'man'
1405 2013-07-22 21:16:25 <gmaxwell> Basically the instructions should be "Distribute exactly."  "Failing that, build with the same diligence we do:  Make public your activities to the bitcoin community (include the nearly 24/7 reachablity of competent help), run these tests, ..."
1406 2013-07-22 21:16:56 <gmaxwell> Luke-Jr: thanks. yea. lets rephrase that a bit.
1407 2013-07-22 21:16:57 CheckDavid has joined
1408 2013-07-22 21:17:22 <Luke-Jr> "uses implementations that have been carefully audited to meet the consensus of the rest of the network" perhaps
1409 2013-07-22 21:17:29 <TheUni> but either way, official requirements/recommendations for the client should be bundled with the client itself, not found by googling for press-releases
1410 2013-07-22 21:17:35 <petertodd> Luke-Jr: +1
1411 2013-07-22 21:17:43 <gmaxwell> Luke-Jr: good, {{sofixit}}
1412 2013-07-22 21:17:56 <gmaxwell> Yea, the statement should just reference it, it's already too long.
1413 2013-07-22 21:18:22 <jgarzik> petertodd, reviewing
1414 2013-07-22 21:19:30 CheckDavid has quit (Read error: Connection reset by peer)
1415 2013-07-22 21:19:51 CheckDavid has joined
1416 2013-07-22 21:20:27 jedunnigan has quit (Remote host closed the connection)
1417 2013-07-22 21:23:36 <gmaxwell> I'm writing "So you want to build some Bitcoin(d/qt):", I'll put it up for revision when I have a first pass done in a few.
1418 2013-07-22 21:23:42 <jgarzik> petertodd, I would include specific examples (link to recent fork portmortem)
1419 2013-07-22 21:23:50 <jgarzik> be specific
1420 2013-07-22 21:23:56 <jgarzik> Your readers are smart, technical people.
1421 2013-07-22 21:24:05 <jgarzik> They just don't know this area of C.S.
1422 2013-07-22 21:24:26 <jgarzik> overall it is still worded like one academic to another, a bit
1423 2013-07-22 21:24:27 skeledrew has quit (Ping timeout: 256 seconds)
1424 2013-07-22 21:24:36 <TheUni> Headline is obvious as-is: "bitcoin devs blast debian for patching their sources"
1425 2013-07-22 21:24:46 wei_ has joined
1426 2013-07-22 21:24:48 <jgarzik> theory is theory.  we have practice, we have field experience to back up this theory.
1427 2013-07-22 21:24:51 <TheUni> again, i very strongly recommend dropping the Debian references
1428 2013-07-22 21:24:57 <jgarzik> +1
1429 2013-07-22 21:25:11 <petertodd> jgarzik: Good idea
1430 2013-07-22 21:26:09 <petertodd> jgarzik: https://en.bitcoin.it/wiki/BIP_0050 link for march chian fork? got a better one in mind?
1431 2013-07-22 21:26:41 <gmaxwell> TheUni: that would be kind of us at least, certatnly "debian fucks up security again by patching shit they don't understand" is a message which, perhaps unfairly, would have a lot of resonance.
1432 2013-07-22 21:27:06 squwiggle has joined
1433 2013-07-22 21:27:07 <sipa> wait, do we know there are actually problems caused by debian patching to use system leveldb?
1434 2013-07-22 21:27:13 <sipa> or is this a guess?
1435 2013-07-22 21:27:30 <gmaxwell> sipa: we do not know that it's leveldb! thats why I keep saying we need to figure that out first.
1436 2013-07-22 21:27:34 <jgarzik> gmaxwell, <grin> this recalls the grand reddit tradition of wildly rewriting an otherwise staid, professional headline
1437 2013-07-22 21:27:34 ahmedbodi has joined
1438 2013-07-22 21:27:40 <TheUni> gmaxwell: yea, if their name is mentioned, all discussion will end. it'll just be a debian packaging circlejerk/flamewar
1439 2013-07-22 21:27:44 taha has joined
1440 2013-07-22 21:27:47 RoboTeddy has quit (Remote host closed the connection)
1441 2013-07-22 21:27:50 <jgarzik> +1
1442 2013-07-22 21:27:55 <gmaxwell> sipa: we know that debian's sid builds are (apparently reliably?) rejecting the chain.
1443 2013-07-22 21:28:03 <gmaxwell> sipa: in some april 2013 block.
1444 2013-07-22 21:28:10 <ahmedbodi> doublec: you here?
1445 2013-07-22 21:28:38 <gmaxwell> dropping all mention of debian has an advantage of letting us not get distracted by the specific incident.
1446 2013-07-22 21:28:51 <TheUni> sipa: you said that there are blacklisted db entries already?
1447 2013-07-22 21:28:57 <ahmedbodi> anyone else here who knows anything about bitcoin's merged mining patch?
1448 2013-07-22 21:28:58 <sipa> TheUni: ?
1449 2013-07-22 21:29:21 <TheUni> gmaxwell, TD, TheUni: regarding leveldb changes - since some 0.8.x change, we detect database errors as separate from validation errors, so they should just cause a quit
1450 2013-07-22 21:29:28 <TheUni> er, your quote ^^
1451 2013-07-22 21:29:35 <sipa> TheUni: yes
1452 2013-07-22 21:29:43 <TheUni> sipa: are those cases in bitcoin_test ?
1453 2013-07-22 21:29:44 <sipa> i'm not sure what that has to do with blacklisting?
1454 2013-07-22 21:29:53 <TheUni> ah i see, nm
1455 2013-07-22 21:29:58 <gmaxwell> TheUni: yes, but only if the _error_ reports as an error.
1456 2013-07-22 21:30:14 <sipa> TheUni: i mean errors like failed to read from disk, or errors from the database layer
1457 2013-07-22 21:30:18 <TheUni> yes, i misread
1458 2013-07-22 21:30:28 <sipa> TheUni: previously they would get the chain that was being connected at that point being marked invalid
1459 2013-07-22 21:31:04 <TheUni> but it is possible in theory to add the current known-busted db entries to a blacklist, no? ignoring the fact that it doesn't help in the future
1460 2013-07-22 21:31:05 * Luke-Jr wonders if the next-test he just released will do IBD successfully <.<  http://bitcointroll.org/?topic=260749
1461 2013-07-22 21:31:50 <Luke-Jr> anyone know if the Debian issue is reproducable with -reindex?
1462 2013-07-22 21:31:56 <sipa> TheUni: there are no "knwon busted entries"
1463 2013-07-22 21:32:01 <sipa> TheUni: if there were, we had a problem
1464 2013-07-22 21:32:05 <gmaxwell> TheUni: if there were any known. (well other than the genesis block's)
1465 2013-07-22 21:32:29 <sipa> Luke-Jr: from what this person was telling on IRC before, it was not deterministic
1466 2013-07-22 21:32:36 <Luke-Jr> ugh
1467 2013-07-22 21:32:36 <sipa> Luke-Jr: and it sounded much more like a hardware problem to me
1468 2013-07-22 21:32:43 <TheUni> gmaxwell: the march split you mentioned above?  it's not possible to trace that to a single verifiable entry somewhere?
1469 2013-07-22 21:32:48 <TheUni> sipa: ok, that answers my question. thanks.
1470 2013-07-22 21:32:51 <Luke-Jr> so it might not even be a Debian fault. definitely let's not blame <.<
1471 2013-07-22 21:32:53 <sipa> TheUni: yes, but only for 0.7
1472 2013-07-22 21:32:58 <sipa> especially since -par=1 fixes it
1473 2013-07-22 21:33:16 <sipa> even with multithreaded verification, db writing is single-threaded
1474 2013-07-22 21:33:27 <sipa> so if it were a leveldb problem, i don't see how -par=1 fixes it
1475 2013-07-22 21:33:33 <sipa> except by loading the CPU less
1476 2013-07-22 21:33:49 <Luke-Jr> that's scary
1477 2013-07-22 21:34:05 <sipa> not more scary than other corruption reports we've had
1478 2013-07-22 21:34:08 <gmaxwell> sipa: doesn't explain why the failure point is apparently consistent.
1479 2013-07-22 21:34:13 <sipa> gmaxwell: is it?
1480 2013-07-22 21:34:22 <sipa> it's certainly not the same block
1481 2013-07-22 21:34:25 <TheUni> maybe debian users are running on old pentium pros that can't add :)
1482 2013-07-22 21:34:44 <sipa> he has reported before that he crashed at some point, and later that he got past it in another run
1483 2013-07-22 21:34:45 <TheSeven> haha. looks like I indeed just broke primecoin by accident...
1484 2013-07-22 21:34:57 <gmaxwell> sipa: indeed.
1485 2013-07-22 21:35:13 <Luke-Jr> TheSeven: not sure anyone cares about primecoin in here
1486 2013-07-22 21:35:31 <gmaxwell> TheSeven: if the problem exists in bitcoin please report the bug. :P
1487 2013-07-22 21:35:48 <gmaxwell> Luke-Jr: the graveyard of failed altcoins is of mild interest.
1488 2013-07-22 21:36:05 <Luke-Jr> gmaxwell: you saw how much primecoin deviated.. :p
1489 2013-07-22 21:36:24 <gmaxwell> Luke-Jr: http://www.despair.com/mistakes.html
1490 2013-07-22 21:36:33 <Luke-Jr> gmaxwell: (your "I'm not sure what this is, but it doesn't belong here")
1491 2013-07-22 21:36:39 agnostic98 has quit (Remote host closed the connection)
1492 2013-07-22 21:36:51 <TheSeven> I just thought I might share it... I somehow managed to generate these not-being-mined txns, and it apparently, despite not being mined, dropped network hashrate by a factor of about >10. what the hell.
1493 2013-07-22 21:37:02 <sipa> gmaxwell: this is very applicable to unit tests :)
1494 2013-07-22 21:37:25 <Luke-Jr> lol
1495 2013-07-22 21:39:31 <petertodd> Other than the document being too long for anyone to sign it, IMO the existing version looks great.
1496 2013-07-22 21:39:32 peetaur2 has quit (Quit: Konversation terminated!)
1497 2013-07-22 21:40:13 <sipa> which document?
1498 2013-07-22 21:40:23 <gmaxwell> sipa: https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#
1499 2013-07-22 21:40:28 <petertodd> sipa: what gmaxwell said
1500 2013-07-22 21:42:16 <TheUni> might also drop the extreme part about "must be fixed within hours or the system is threatened"
1501 2013-07-22 21:42:31 <TheUni> headline: "one change by distro maintainers could wipe our your life savings"
1502 2013-07-22 21:43:33 <petertodd> TheUni: s/survival/functionality/ ?
1503 2013-07-22 21:44:54 <petertodd> Removed the 'consistency more important than correctness' line for the same headline generating reasons...
1504 2013-07-22 21:45:01 <gmaxwell> aww.
1505 2013-07-22 21:45:02 <gmaxwell> :P
1506 2013-07-22 21:45:10 <Luke-Jr> having my wife proofread it
1507 2013-07-22 21:45:56 <petertodd> gmaxwell: hurt to do that
1508 2013-07-22 21:46:57 skeledrew has joined
1509 2013-07-22 21:47:13 <TheUni> petertodd: "...could necessitate manual intervention by users and devs alike" or so, is what i had in mind
1510 2013-07-22 21:47:25 cyrozap has quit (Quit: Bye!)
1511 2013-07-22 21:47:30 <gmaxwell> TheUni: it's not just manual intervention.
1512 2013-07-22 21:47:40 <gmaxwell> a bad enough consensus fail could actually be the end of bitcoin.
1513 2013-07-22 21:48:13 <gmaxwell> e.g. if someone manages a multi doublespend against two large merchants.. it would be really hard to rebuild confidence in bitcoin.
1514 2013-07-22 21:48:31 <TheUni> gmaxwell: lots of things could be the end of bitcoin, but stressing them during routine PR is not exactly going to give anyone a warm feeling
1515 2013-07-22 21:48:44 <petertodd> TheUni: agreed
1516 2013-07-22 21:48:55 <gmaxwell> right, I'm fine with not saying loud things. But we shouldn't say things which underplay the risk either.
1517 2013-07-22 21:49:21 <TheUni> need to decide on an end goal: are we stressing what the consequences of not making this change could be? or are we trying to get the change made?
1518 2013-07-22 21:49:24 <gmaxwell> E.g. Just say this is important. Don't say "this is important because a couple people might have mildly bad day"
1519 2013-07-22 21:49:40 <gmaxwell> (if the consequence is really a lot worse)
1520 2013-07-22 21:49:40 <warren> Can we consider upgrading the library deps in gitian for bitcoin-0.9?
1521 2013-07-22 21:49:40 <TheUni> cause those are 2 different perspectives, which require their own tones
1522 2013-07-22 21:49:50 <sipa> warren: sure
1523 2013-07-22 21:50:29 <petertodd> gmaxwell: "is a critical problem that threatens the functionality and security of the system for all users" <- happy with that?
1524 2013-07-22 21:50:39 vbuterin has joined
1525 2013-07-22 21:50:50 <Luke-Jr> warren: just needs a pullreq and some audits
1526 2013-07-22 21:50:52 <TheUni> gmaxwell: not trying to be a contrarian here, just taking the typical PR approach of "never say anything bad about your product"
1527 2013-07-22 21:50:59 <warren> hmm, I wonder what versions we should use.
1528 2013-07-22 21:51:04 <TheUni> imo that goes a long way
1529 2013-07-22 21:51:20 <TheUni> warren: whatever is current in gitian distro should be reference for the rest
1530 2013-07-22 21:51:38 <TheUni> ^^ easy rule of thumb. that way all OS's can align
1531 2013-07-22 21:51:38 <gmaxwell> TheUni: Bitcoin is risky enough that I feel that we have a bit of a moral obligation to be frank. Obviously we don't want to caused confused panic either, but we should generally error towards being frank.
1532 2013-07-22 21:51:49 <petertodd> gmaxwell: agreed
1533 2013-07-22 21:52:01 <sipa> i think we should first at least get clarification whether this is a consistent block that triggers the bug
1534 2013-07-22 21:52:33 <warren> TheUni: btw, have you submitted autotool and gitian fixes for secp256k1, in addition to autotooling bitcoin master?
1535 2013-07-22 21:52:55 <petertodd> sipa: IMO the advice is good and something we should be saying, though I agree that clear evidence of a problem first is better
1536 2013-07-22 21:53:01 <gmaxwell> sipa: ignoring the debian thing, knowing that they're patching out our internal leveldb it's probably prudent to say something here.
1537 2013-07-22 21:53:26 <sipa> gmaxwell: agree, but if there is no direct threat here, i'd rather not have it linked to it
1538 2013-07-22 21:53:30 <gmaxwell> This no longer mentions our specific concerns with debian.. also I believe arch is doing the same thing.
1539 2013-07-22 21:53:37 <TheUni> warren: no
1540 2013-07-22 21:53:47 <gmaxwell> sipa: agree, but I think thats fixed now.
1541 2013-07-22 21:54:05 <warren> If fedora gets past the EC issue, they'll insist on similarly not shipping "redundant" libraries, which will be a problem here...
1542 2013-07-22 21:54:22 <TheUni> EC issue?
1543 2013-07-22 21:54:32 <gmaxwell> TheUni: redhat strips ECC support from openssl.
1544 2013-07-22 21:54:37 <gmaxwell> (though note: they have it in NSS now)
1545 2013-07-22 21:54:43 <TheUni> i still say a library rename is in order, btw
1546 2013-07-22 21:54:48 <Luke-Jr> warren: all the more reason to swtich to sipa's secp256k1 :D
1547 2013-07-22 21:54:53 <petertodd> How about instead of "this requirement is not compatible" say "For instance even simply replacing the included leveldb library with a system library is a change that requires careful auditing."
1548 2013-07-22 21:54:53 <sipa> TheUni: to?
1549 2013-07-22 21:55:07 <gmaxwell> TheUni: openssl's ECC support mixes up a bunch of probably patented optimizations and clearly not-patented stuff, so they just turn it all off.
1550 2013-07-22 21:55:15 <warren> Luke-Jr: yeah, with that at least fedora/RHEL users will be able to build it without replacing their openssl
1551 2013-07-22 21:55:22 <Luke-Jr> petertodd: *constant* careful auditing!
1552 2013-07-22 21:55:23 <TheUni> sipa: leveldb -> bitcoindb. If leveldb can never be dropped in, calling it leveldb can only be a bad thing
1553 2013-07-22 21:55:34 <warren> TheUni: good idea
1554 2013-07-22 21:55:34 <sipa> oh, that
1555 2013-07-22 21:55:44 <petertodd> Luke-Jr: good point
1556 2013-07-22 21:55:45 <sipa> i though you were talking about libsecp256k1 :)
1557 2013-07-22 21:55:52 <Luke-Jr> TheUni: leveldb *can* be dropped it, it just requires care
1558 2013-07-22 21:55:53 <warren> call the db a "fork".
1559 2013-07-22 21:55:55 <TheUni> sipa: hehe, nah, that's all yours :)
1560 2013-07-22 21:56:07 <Luke-Jr> TheUni: Gentoo does and will continue to do so, since its packaging system is capable of that care
1561 2013-07-22 21:56:23 <warren> TheUni: and people can colloquially call it "bdb"
1562 2013-07-22 21:56:24 <warren> oh wait
1563 2013-07-22 21:56:25 <TheUni> Luke-Jr: that "care" requires using old versions and/or patching, right?
1564 2013-07-22 21:56:30 stamit has joined
1565 2013-07-22 21:56:32 <TheUni> warren: that's a terrible idea :)
1566 2013-07-22 21:56:38 <phantomcircuit> TheUni, requires specific versions
1567 2013-07-22 21:56:40 <gmaxwell> TheUni: gentoo's package enviroment is able to enforce a specific version _exactly_.
1568 2013-07-22 21:56:42 <Luke-Jr> TheUni: there is a dependency on the specific version bundled, basically
1569 2013-07-22 21:56:50 <phantomcircuit> JYNX ON ALL OF YOU
1570 2013-07-22 21:56:50 <Luke-Jr> TheUni: with the specific build flags we use
1571 2013-07-22 21:56:51 <TheUni> Luke-Jr: right, so it's not a drop-in going forward
1572 2013-07-22 21:57:04 <petertodd> Luke-Jr: how's that language?
1573 2013-07-22 21:57:06 <TheUni> it's a snapshot of an old version that's not compatible with the current leveldb development, right?
1574 2013-07-22 21:57:17 <sipa> TheUni: it is compatible
1575 2013-07-22 21:57:31 <Luke-Jr> FWIW, other Gentoo packages using leveldb: dev-libs/replicant net-fs/cvmfs net-misc/elliptics sys-cluster/ceph
1576 2013-07-22 21:57:38 <Luke-Jr> petertodd: ?
1577 2013-07-22 21:57:47 David_ has joined
1578 2013-07-22 21:57:57 <petertodd> Luke-Jr: I mean, I changed it to talk about constant auditing re: shared libraries
1579 2013-07-22 21:58:07 <warren> "bdb" is compatible too, and it's a major source of headaches for users.
1580 2013-07-22 21:58:15 <TheUni> sipa: sorry, poor choice of words. what i meant is this: the version of leveldb produced by gentoo is effectively what would be called "bitcoindb" if it were renamed
1581 2013-07-22 21:58:24 <Luke-Jr> petertodd: ah, I'd stress constant more.. it's important that distros realize they will need to audit *ever* *single* *bump* to the lib
1582 2013-07-22 21:58:27 <sipa> TheUni: not sure what you mean by that
1583 2013-07-22 21:58:28 <warren> TheUni: how about coindb?
1584 2013-07-22 21:58:41 <sipa> TheUni: the databases we write can be read/modified by any recent leveldb version
1585 2013-07-22 21:58:41 yubrew has joined
1586 2013-07-22 21:58:46 <TheUni> warren: heh, the name is not really the matter at hand :)
1587 2013-07-22 21:59:08 <Luke-Jr> TheUni: we will probably upgrade LevelDB for 0.9
1588 2013-07-22 21:59:11 <TheUni> sipa: and the latest stable would cause a disagreement in clients, no?
1589 2013-07-22 21:59:18 <sipa> TheUni: highly unlikely
1590 2013-07-22 21:59:20 <Luke-Jr> TheUni: we don't know if it would
1591 2013-07-22 21:59:22 <sipa> TheUni: but there is a risk
1592 2013-07-22 21:59:36 <Luke-Jr> TheUni: the point is, before upgrading it, *someone* MUST do a careful review
1593 2013-07-22 21:59:55 TD has quit (Quit: TD)
1594 2013-07-22 21:59:59 <Luke-Jr> TheUni: if Debian wants to add that to their process, that's fine. but most likely the easiest option for them is to leave it embedded.
1595 2013-07-22 22:00:09 <TheUni> Luke-Jr: if that's the point, then you can't also make the point that it's generally compatible with the upstream version
1596 2013-07-22 22:00:11 CheckDavid has quit (Ping timeout: 246 seconds)
1597 2013-07-22 22:00:13 <sipa> yes, i am in favor of upgrading leveldb - i've gone through the changes, and didn't find anything that should affect us, but i didn't look that deep either
1598 2013-07-22 22:00:13 David_ has quit (Client Quit)
1599 2013-07-22 22:00:16 <TheUni> if it requires the "after careful review" qualifier
1600 2013-07-22 22:00:42 CheckDavid has joined
1601 2013-07-22 22:00:54 <Luke-Jr> TheUni: that is true for EVERY one of our deps, arguably
1602 2013-07-22 22:01:39 <Luke-Jr> who is Cookie Monster?
1603 2013-07-22 22:01:45 <TheUni> Luke-Jr: i'm only arguing that if the general concensus is to require a snapshotted, patched version of leveldb at all times, then we have become maintainers of a fork that closely follows an upstream. and it should be treated as such
1604 2013-07-22 22:01:59 <sipa> it is not about leveldb itself - if there are no bugs in it, there is no problem (and if there is, they have a problem)
1605 2013-07-22 22:02:07 <Luke-Jr> TheUni: we do no patching
1606 2013-07-22 22:02:11 <warren> TheUni: https://github.com/sipa/bitcoin/commits/secp256k1   bitcoin patched for secp256k1.  I highly recommend prepping this repo for the autotools change too.
1607 2013-07-22 22:02:26 <sipa> Luke-Jr: we do
1608 2013-07-22 22:02:31 <sipa> Luke-Jr: especially the windows branch
1609 2013-07-22 22:02:41 <Luke-Jr> oh, well, Windows isn't really a concern here..
1610 2013-07-22 22:02:48 <sipa> it absolutely is
1611 2013-07-22 22:02:59 <Luke-Jr> I don't see Microsoft doing a Bitcoin-Qt distro..
1612 2013-07-22 22:03:05 <TheUni> it is if the same source can't be used as a reference across the board
1613 2013-07-22 22:03:34 <TheUni> ok, i've made made my opinion known. you guys can hash it out :)
1614 2013-07-22 22:03:42 <warren> Luke-Jr: you're underestimating the resistance we have from distros who have a hard line stance against using embedded libraries.  Declaring our internal db a "fork" with a different name will entirely allow it to sidestep at least fedora's policy.
1615 2013-07-22 22:04:32 <TheUni> sipa: re the above, how do you see secp256k1 being hooked up?
1616 2013-07-22 22:04:41 <TheUni> part of the bitcoin tree? or out of tree?
1617 2013-07-22 22:04:48 <sipa> TheUni: right now, out
1618 2013-07-22 22:05:04 <sipa> there are several people who are interested in it, outside of bitcoin
1619 2013-07-22 22:05:14 <TheUni> sipa: when it hits master, still out?
1620 2013-07-22 22:05:25 <sipa> probably similarly to leveldb
1621 2013-07-22 22:05:33 <TheUni> so.. in :)
1622 2013-07-22 22:05:34 <sipa> maintained out of tree, but with snapshotted versions copied in
1623 2013-07-22 22:05:58 Applicat_ has joined
1624 2013-07-22 22:06:01 <TheUni> ok. so it'd still need its own buildsystem then
1625 2013-07-22 22:06:06 <warren> sipa: please call the one in bitcoin a 'fork' as merely a policy issue
1626 2013-07-22 22:06:11 agnostic_ has joined
1627 2013-07-22 22:06:27 <sipa> warren: https://github.com/bitcoin/leveldb
1628 2013-07-22 22:06:34 RoboTeddy has joined
1629 2013-07-22 22:06:39 <warren> nice
1630 2013-07-22 22:06:45 <sipa> TheUni: jgarzik once offerred autotoolsifying libsecp256k1, but never got to it
1631 2013-07-22 22:06:59 <warren> sipa: can we rename it to make it more obviously a "fork"?
1632 2013-07-22 22:07:00 <sipa> i would certainly like a more professional build env for it
1633 2013-07-22 22:07:07 <TheUni> sipa: sure you're not thinking of of me? i offered the same at one point
1634 2013-07-22 22:07:13 <sipa> TheUni: i know
1635 2013-07-22 22:07:16 <TheUni> ok
1636 2013-07-22 22:07:56 <sipa> TheUni: you're very welcome to do so, but i'd rather get bitcoin autotoolsified now :)
1637 2013-07-22 22:08:15 <TheUni> sipa: offer back on the table after bitcoin PR goes in, so that i'm not actively working on 2 at once
1638 2013-07-22 22:08:38 <TheUni> if someone beats me to it, all the better :)
1639 2013-07-22 22:08:47 Application has quit (Ping timeout: 248 seconds)
1640 2013-07-22 22:08:54 <sipa> warren: as long as it is 1) backward+forward compatible with leveldb and  2) intended to be useful for projects that are not bitcoin -> no
1641 2013-07-22 22:09:15 <warren> sipa: secp256k1 for bitcoin-0.9 is currently a stretch goal?
1642 2013-07-22 22:09:18 <phantomcircuit> lol bernanke
1643 2013-07-22 22:09:32 <sipa> warren: i think so
1644 2013-07-22 22:09:49 <TheUni> sipa: as an option? or on?
1645 2013-07-22 22:09:50 <sipa> (my english fails me here... by stretch goal, you mean something unlikely to happen?)
1646 2013-07-22 22:10:00 <warren> sipa: I'm just saying I don't want fedora to use its system leveldb, and they will force the issue if the leveldb in bitcoin is named as such.
1647 2013-07-22 22:10:46 <warren> sipa: stretch goal ... if primary objectives are completed and we have enough time to ensure secp256k1 is safe
1648 2013-07-22 22:10:47 <sipa> warren: if gmaxwell's letter isn't convincing enough, we shouldn't falsify the facts
1649 2013-07-22 22:11:06 <gmaxwell> Here is a first rough stab at some guidance that could be checked into git about building binaries for others: https://docs.google.com/document/d/1b1WKdvUl8K8mdNA9yTx2ATg97tpWPEL8NUpWRTob5Tw/edit
1650 2013-07-22 22:11:17 <warren> Is it really a falsification?  It's a fork that is tested for this purpose.
1651 2013-07-22 22:11:19 <gmaxwell> please feel free to hack on it some if you're interested.
1652 2013-07-22 22:11:28 <petertodd> gmaxwell: isn't public
1653 2013-07-22 22:11:31 <gmaxwell> warren: which may happen at some point or another to be identical to upstream.
1654 2013-07-22 22:11:43 <warren> gmaxwell: that'd be perfect
1655 2013-07-22 22:11:58 copumpkin has quit (Ping timeout: 246 seconds)
1656 2013-07-22 22:12:15 <sipa> warren: but even if it goes into upstream at some point, we'll still keep out own copy
1657 2013-07-22 22:12:20 <sipa> not because it is different
1658 2013-07-22 22:12:22 patcon has quit (Remote host closed the connection)
1659 2013-07-22 22:12:25 <phantomcircuit> petertodd, actually it is you just gotta change the url a bit
1660 2013-07-22 22:12:27 <sipa> but because we need controlled changes
1661 2013-07-22 22:12:35 <warren> wait, "it goes into usptream" is what?
1662 2013-07-22 22:12:40 copumpkin has joined
1663 2013-07-22 22:12:57 <gmaxwell> Try again: https://docs.google.com/document/d/1b1WKdvUl8K8mdNA9yTx2ATg97tpWPEL8NUpWRTob5Tw/edit
1664 2013-07-22 22:13:23 <warren> sipa: the point here is bitcoin cannot risk arbitrary changes in the system library.  Upstreaming things doesn't help this issue.
1665 2013-07-22 22:13:36 <gmaxwell> Have you all read the color of your bits essay?
1666 2013-07-22 22:13:49 <petertodd> gmaxwell: "color of your bits" ?
1667 2013-07-22 22:14:07 <gmaxwell> petertodd: http://ansuz.sooke.bc.ca/entry/23
1668 2013-07-22 22:14:25 <gmaxwell> We need software which has a tested-for-bitcoin-consistency color, which isn't something you can see in any patch.
1669 2013-07-22 22:15:06 <warren> there's precedent for this in distros, they stick to certain versions of old software or ship it separately because it is the only version certified by <authority>
1670 2013-07-22 22:15:22 <TheUni> btw, autotools will allow testing for specific versions of libs, so it's easier to kick out with "this version does not work, do not patch this out"
1671 2013-07-22 22:15:36 <TheUni> doesn't help in the case of leveldb, but would with openssl and others
1672 2013-07-22 22:15:42 <gmaxwell> TheUni: except distros regularly patch packages while keeping the versions the same. :(
1673 2013-07-22 22:15:58 <phantomcircuit> lol debian
1674 2013-07-22 22:16:05 <warren> Please just declare the tested-for-consistency library version as a fork with its own name.  distro policy would probably mean it ships as a dynamic library to be used by arbitrary other software that links to it.
1675 2013-07-22 22:16:18 <TheUni> gmaxwell: sure, just saying they'd have to litterally remove the warning telling them not to do what they're doing
1676 2013-07-22 22:16:39 Application has joined
1677 2013-07-22 22:16:41 <TheUni> *literally
1678 2013-07-22 22:17:24 stamit has left ()
1679 2013-07-22 22:17:45 <petertodd> gmaxwell: ah, yeah that one's good
1680 2013-07-22 22:18:12 <gmaxwell> TheUni: http://pastebin.mozilla.org/2689635 OpenSSL's patches in fedora. :P
1681 2013-07-22 22:18:38 <TheUni> gmaxwell: to be far, openssl is a maintainer's nightmare
1682 2013-07-22 22:18:38 <Luke-Jr> TheUni: --with-system-leveldb='I have read doc/packaging with SHA256 <hash> and understand the risks'
1683 2013-07-22 22:19:03 <TheUni> gmaxwell: have you tried working with their buildsystem for some exotic arch?
1684 2013-07-22 22:19:04 <warren> TheUni: lots of that is for their government certification.  I don't know the story of why things are needed in there.
1685 2013-07-22 22:19:14 <TheUni> put it this way.. i think i'd rather work with boost's bjam
1686 2013-07-22 22:19:18 Applicat_ has quit (Ping timeout: 256 seconds)
1687 2013-07-22 22:19:18 <gmaxwell> TheUni: 22792 lines of patch. :P
1688 2013-07-22 22:20:07 <TheUni> heh
1689 2013-07-22 22:20:14 <petertodd> gmaxwell: that's like 10x more lines of code than I've written for Bitcoin...
1690 2013-07-22 22:21:00 <TheUni> it's a nightmarish lump of code. I can see what that level of patching would be required
1691 2013-07-22 22:21:03 <warren> It's huge patches, but I wouldn't be surprised if the government and contractors were involved in auditing it.
1692 2013-07-22 22:21:10 <petertodd> gmaxwell: "so you want to" doc looks good to me generally, good to be clear as to exactly what a break of consensus does too
1693 2013-07-22 22:21:19 <petertodd> gmaxwell: *good that you are clear
1694 2013-07-22 22:21:22 <gmaxwell> But as I said before, I think that leveldb has a lot more risk of unnoticed bitcoin specific breakage than openssl.
1695 2013-07-22 22:21:36 <warren> thus, please rename and declare it a fork
1696 2013-07-22 22:22:40 <lianj> did anything change about how txs that depends on other unconfirmed txs that are already in the memory pool are relayed/broadcasted?
1697 2013-07-22 22:23:02 <sipa> lianj: the mempool does not rebroadcast - wallets do
1698 2013-07-22 22:23:15 imton has joined
1699 2013-07-22 22:23:15 bbrian has joined
1700 2013-07-22 22:23:16 <sipa> nothing changed wrt that in the past... years afaik
1701 2013-07-22 22:23:39 <phantomcircuit> sipa, he's trying to figure out why chained dependent unconfirmed transactions aren't being relayed
1702 2013-07-22 22:23:49 <gmaxwell> I wish I knew which software was the agressive rebroadcaster.
1703 2013-07-22 22:23:52 <warren> phantomcircuit: aren't being relayed by whom?
1704 2013-07-22 22:24:04 agricocb has quit (Quit: Leaving.)
1705 2013-07-22 22:24:06 <Luke-Jr> gmaxwell: bitcoin-ruby? :p
1706 2013-07-22 22:24:08 <TheUni> warren: in case you didn't see above, i have bitcoind up and running on android. looking to see if there's any interest in actively working on it
1707 2013-07-22 22:24:14 <phantomcircuit> some % of the network significant enough to cause a propagation issue
1708 2013-07-22 22:24:18 <gmaxwell> there is some node out there which appears to be agressively rebroadcasting its mempool every block. it wastes a bunch of bandwidth.
1709 2013-07-22 22:24:34 <Luke-Jr> gmaxwell: no UA?
1710 2013-07-22 22:24:37 <lianj> not rebroadcast, just relay. hm ok thanks. seeing issues where pushing one tx and another tx that depends on the previous one a second later results in not showing up on blockchain.info/blockexplorer. but if i ask the node i pushed it to it has both inside his memory pool
1711 2013-07-22 22:24:41 <warren> TheUni: that's cool, but perhaps more useful when bitcoind grows the proposed SPV mode discussed on the list.
1712 2013-07-22 22:24:50 <sipa> we may need a negative mempool, i.e. a list of invs that we know about though have deleted ourself
1713 2013-07-22 22:25:08 <TheUni> warren: spv mode? link?
1714 2013-07-22 22:25:11 <petertodd> sipa: absolutely required IMO
1715 2013-07-22 22:25:12 <sipa> which are actively ignored when announced
1716 2013-07-22 22:25:13 <Luke-Jr> sipa: bloom filter?
1717 2013-07-22 22:25:16 <warren> TheUni: follow bitcoin dev mailing list
1718 2013-07-22 22:25:25 <TheUni> crap, back in 30
1719 2013-07-22 22:25:30 <gmaxwell> Luke-Jr: I think it claims to be bitcoin-qt.
1720 2013-07-22 22:25:48 <petertodd> Luke-Jr: IMO bloom not ok given the use of bitcoind to protect non-bitcoind nodes
1721 2013-07-22 22:26:01 <sipa> agree with petertodd
1722 2013-07-22 22:26:03 <petertodd> Luke-Jr: (you can't even not apply it to wallet-related, it'll still break stuff)
1723 2013-07-22 22:26:12 <phantomcircuit> gmaxwell, 4000 * 500 * 36 bytes / 10 minutes ~= 120 KB/s to broadcast 500 transactions via inv (assuming most people already have them)
1724 2013-07-22 22:26:23 <warren> petertodd: how much work will the partial UTXO thing be?
1725 2013-07-22 22:26:25 <petertodd> Luke-Jr: Granted 2^-64 probability is fine, so it can truncate hashes.
1726 2013-07-22 22:26:30 <phantomcircuit> it's like 30 baud per peer
1727 2013-07-22 22:26:31 <petertodd> warren: Lots...
1728 2013-07-22 22:26:45 <petertodd> warren: Still looking at it, though sipa's done some of the work re: header sync.
1729 2013-07-22 22:26:50 <warren> ah
1730 2013-07-22 22:27:22 <midnightmagic> sipa: There's something like it in the transaction non-relay patches floating around, so people (myself included) are already running a sort-of negative mempool mechanism.
1731 2013-07-22 22:27:45 <sipa> actually
1732 2013-07-22 22:27:47 <phantomcircuit> midnightmagic, that could be an issue actually if done poorly
1733 2013-07-22 22:27:56 <petertodd> Luke-Jr: (tuncation requirs per-node seed though at 2^-64, that's not secure re: birthday attack in principle)
1734 2013-07-22 22:27:57 <phantomcircuit> you could essentially permanently blacklist a transaction
1735 2013-07-22 22:27:59 bbrian has quit (Client Quit)
1736 2013-07-22 22:28:21 <sipa> i think header-first sync will be useful pretty soon
1737 2013-07-22 22:28:22 <Luke-Jr> well, be careful not to add a memory exhaustion leak
1738 2013-07-22 22:28:23 <midnightmagic> phantomcircuit: that's the idea. at least until some other chump includes it in a block.
1739 2013-07-22 22:28:26 <Luke-Jr> vuln*
1740 2013-07-22 22:28:33 <sipa> i need to figure out some heuristics for downloading still
1741 2013-07-22 22:28:44 <sipa> perhaps i can just do a simple download-from-one-node for now
1742 2013-07-22 22:28:46 <petertodd> Luke-Jr: my idea would be the blacklist would be on disk actually
1743 2013-07-22 22:29:02 <phantomcircuit> petertodd, nope * 1000
1744 2013-07-22 22:29:10 <petertodd> phantomcircuit: rational?
1745 2013-07-22 22:29:12 vbuterin has quit (Ping timeout: 264 seconds)
1746 2013-07-22 22:29:55 <phantomcircuit> petertodd, having multiple databases on disk which a remote peer can cause churn on is a bad idea
1747 2013-07-22 22:30:05 <phantomcircuit> conventional hdds deal *very* poorly with that type of access
1748 2013-07-22 22:30:09 tcatm has quit (Read error: Connection reset by peer)
1749 2013-07-22 22:30:26 <petertodd> phantomcircuit: Hmm... so you figure the UTXO lookup + blacklist lookup is unacceptable basically? One or the other?
1750 2013-07-22 22:30:31 tcatm has joined
1751 2013-07-22 22:30:31 tcatm has quit (Changing host)
1752 2013-07-22 22:30:31 tcatm has joined
1753 2013-07-22 22:30:49 <phantomcircuit> petertodd, unless you enjoy the sound of *click* *click* *click*
1754 2013-07-22 22:31:39 <warren> phantomcircuit: does bitcoind relay orphan tx at all?  I've seen mine accept() it but not relay it
1755 2013-07-22 22:32:17 <phantomcircuit> i dont think so but i'd have to check that one
1756 2013-07-22 22:32:18 <warren> I was creating orphan tx's on purpose to test what I thought was bug.  It wasn't a bug.
1757 2013-07-22 22:32:52 <sipa> no
1758 2013-07-22 22:32:54 <Luke-Jr> warren: it can't.
1759 2013-07-22 22:33:03 <sipa> only things that enter the mempool are relayed
1760 2013-07-22 22:33:04 <Luke-Jr> warren: relaying orphan tx would make it vulnerable to DoS
1761 2013-07-22 22:33:14 tcatm has quit (Read error: Connection reset by peer)
1762 2013-07-22 22:33:17 <warren> ok, that's what I thought
1763 2013-07-22 22:33:32 tcatm has joined
1764 2013-07-22 22:33:36 <warren> lianj: you're seeing orphan tx not relay at all after their parents appear?
1765 2013-07-22 22:33:44 <petertodd> phantomcircuit: Hmm... well minimum transaction size is 156 currently, and absolute minimum is ~64, so a in-memory blacklist saves you 20x to 8x roughly. Worth it still I agree.
1766 2013-07-22 22:34:12 <petertodd> phantomcircuit: Probably best to kick nodes if they send us huge numbers of tx's that wind up in the blacklist instead.
1767 2013-07-22 22:34:19 tcatm has quit (Remote host closed the connection)
1768 2013-07-22 22:34:20 <phantomcircuit> petertodd, yup
1769 2013-07-22 22:34:37 tcatm has joined
1770 2013-07-22 22:34:55 <sipa> with blacklist, you mean what i called negative mempool before?
1771 2013-07-22 22:35:01 <lianj> warren: no, once the parent makes it into a block and we rebroadcast it again it starts to show up on blockchain.ifno aswell, just not while the parent isn't confirmed yet. which is weird because this behavior is new
1772 2013-07-22 22:35:34 <sipa> lianj: sounds like exactly the intended behaviour
1773 2013-07-22 22:35:44 datagutt has quit (Quit: Computer has gone to sleep.)
1774 2013-07-22 22:35:48 <sipa> lianj: but maybe b.i worked differently before, and somehow it did reach them?
1775 2013-07-22 22:36:12 <sipa> lianj: oh wait
1776 2013-07-22 22:36:20 <sipa> the parent shouldn't need to be confirmed
1777 2013-07-22 22:36:23 <sipa> just known
1778 2013-07-22 22:37:00 <petertodd> lianj: blockchain.info filters out tx's with unconfirmed parents unless the parent was sent to b.i through their /pushtx facility
1779 2013-07-22 22:37:10 <petertodd> lianj: they started doing that after the nLockTime thing
1780 2013-07-22 22:37:29 <gmaxwell> crud, looks like troublemakers have been crapping on the document
1781 2013-07-22 22:38:28 <sipa> gmaxwell: how so?
1782 2013-07-22 22:38:38 <warren> he made it public editable
1783 2013-07-22 22:38:51 <sipa> i see no vandalism?
1784 2013-07-22 22:38:55 <gmaxwell> I removed some of it.
1785 2013-07-22 22:38:58 tcatm has quit (Remote host closed the connection)
1786 2013-07-22 22:39:18 tcatm has joined
1787 2013-07-22 22:39:18 tcatm has quit (Changing host)
1788 2013-07-22 22:39:18 tcatm has joined
1789 2013-07-22 22:39:51 <lianj> petertodd: thanks, thats a good datapoint, but the locktime thing was months ago. and we are starting to see it just now (1-2weeks(
1790 2013-07-22 22:40:30 <petertodd> lianj: example tx?
1791 2013-07-22 22:40:31 <TheUni> warren: that discussion seems a bit over my head as i'm not yet very familiar with bitcoind's internals. But once in, I can make android happen if that's desired
1792 2013-07-22 22:41:22 Krellan_ has joined
1793 2013-07-22 22:41:38 <warren> TheUni: will the new autotoolified source allow make to actually reuse objects if unchanged?  currently -qt builds don't seem to.
1794 2013-07-22 22:41:43 <lianj> petertodd: hold on, let my look for a current one
1795 2013-07-22 22:41:56 <TheUni> reuse if unchanged?
1796 2013-07-22 22:42:04 <sipa> warren: we do reuse objects if unchanged
1797 2013-07-22 22:42:08 <warren> hmm
1798 2013-07-22 22:42:10 <warren> I wonder why mine isn't
1799 2013-07-22 22:42:22 <warren> bitcoind builds only what changed, but -qt doesn't
1800 2013-07-22 22:42:38 <sipa> oh, don't know about -qt
1801 2013-07-22 22:42:46 <TheUni> warren: not sure what you're asking, but to try to answer your question, yes, it tracks dependencies and only rebuilds what was touched
1802 2013-07-22 22:42:49 <sipa> i build that once a month or so
1803 2013-07-22 22:43:34 <TheUni> warren: also it detects and uses ccache. so 2nd build from clean source takes about 5sec
1804 2013-07-22 22:43:41 <warren> nice
1805 2013-07-22 22:43:51 bbrian has joined
1806 2013-07-22 22:44:25 <warren> TheUni: as soon as our auditor finishes and we release 0.8.3.x I'll help by getting my team to test the autotools PR on multiple platforms
1807 2013-07-22 22:44:39 <TheUni> great
1808 2013-07-22 22:44:39 <phantomcircuit> lianj, have you tried mapping which listening peers accept them?
1809 2013-07-22 22:44:53 <Luke-Jr> is the "Linux distribution packaging and Bitcoin" note done? time to add signatures?
1810 2013-07-22 22:44:57 <TheUni> warren: got it signed-off today, so afaik it's ready to go as soon as i squash and document it
1811 2013-07-22 22:45:04 <warren> TheUni: our devs run 3 different distros, mac and windows
1812 2013-07-22 22:45:09 <Luke-Jr> (and was Gavin's actually added by Gavin?)
1813 2013-07-22 22:45:11 <warren> TheUni: cool
1814 2013-07-22 22:45:12 <phantomcircuit> lianj, should be able to do it by abusing two connections to each listening peer, one of them sends the two transactions, the other listens to see if that peer forwards them
1815 2013-07-22 22:49:16 <petertodd> Luke-Jr: IMO it should be a text document with PGP signatures...
1816 2013-07-22 22:49:46 <Luke-Jr> petertodd: good idea; although a list of names would be nice for publishing on eg blogs and such
1817 2013-07-22 22:49:58 <petertodd> Luke-Jr: yeah, do both
1818 2013-07-22 22:50:20 <warren> bbl
1819 2013-07-22 22:51:18 <lianj> phantomcircuit: petertodd just verified again, like we guessed yesterday that it seems to be a blockchain.info thing/issue only. which is still annoying but closes the confusing
1820 2013-07-22 22:51:30 <petertodd> Luke-Jr: You can concatenate cleartext sigs FWIW: https://litecoin.org/archive/2013/litecoin-0.8.3.x-code-audit-agreement.txt.asc
1821 2013-07-22 22:51:39 theo_ has joined
1822 2013-07-22 22:52:28 Thepok has quit (Quit: Nettalk6 - www.ntalk.de)
1823 2013-07-22 22:55:08 xire has joined
1824 2013-07-22 22:55:08 xire has quit (Changing host)
1825 2013-07-22 22:55:08 xire has joined
1826 2013-07-22 22:55:59 one_zero has joined
1827 2013-07-22 22:56:23 sacredchao has quit (Ping timeout: 240 seconds)
1828 2013-07-22 22:56:33 ralphthe1inja has joined
1829 2013-07-22 22:56:34 ielo has joined
1830 2013-07-22 22:56:51 xnyhps_ has joined
1831 2013-07-22 22:57:59 ielo has quit (Client Quit)
1832 2013-07-22 22:58:29 sacredchao has joined
1833 2013-07-22 22:59:32 Zoop57 has joined
1834 2013-07-22 23:00:36 oru_ has joined
1835 2013-07-22 23:00:44 cads has quit (Ping timeout: 268 seconds)
1836 2013-07-22 23:01:14 gavinandresen has joined
1837 2013-07-22 23:01:20 hnz has quit (Ping timeout: 268 seconds)
1838 2013-07-22 23:01:54 mcm has joined
1839 2013-07-22 23:02:39 BurtyB has joined
1840 2013-07-22 23:02:43 mcm has quit (Client Quit)
1841 2013-07-22 23:02:56 mcm has joined
1842 2013-07-22 23:02:56 mcm has quit (Changing host)
1843 2013-07-22 23:02:56 mcm has joined
1844 2013-07-22 23:03:58 <Luke-Jr> petertodd: it doesn't play too nicely with Markdown, however: https://gist.github.com/luke-jr/6058439
1845 2013-07-22 23:04:25 mcm has quit (Client Quit)
1846 2013-07-22 23:04:57 hnz has joined
1847 2013-07-22 23:05:08 <petertodd> Luke-Jr: annoying
1848 2013-07-22 23:05:37 <petertodd> Luke-Jr: ugh, looooong lines... :)
1849 2013-07-22 23:05:49 <petertodd> Luke-Jr: I think it's fine then for it to just be in text like everything else then
1850 2013-07-22 23:06:01 <gmaxwell> how can we concat clearsigs? I agree this thing ought to be gpg signed.
1851 2013-07-22 23:06:02 <petertodd> Luke-Jr: make up a PDF for the "press" later
1852 2013-07-22 23:06:17 <petertodd> gmaxwell: see how it's done here: https://litecoin.org/archive/2013/litecoin-0.8.3.x-code-audit-agreement.txt.asc
1853 2013-07-22 23:06:22 <petertodd> gmaxwell: turns out it's really easy
1854 2013-07-22 23:06:32 <Luke-Jr> petertodd: markdown can work good enough for raw text
1855 2013-07-22 23:06:33 <Luke-Jr> https://gist.github.com/luke-jr/6058439/raw/0dba9c1ba8f110c8043e67bbde2d2c1c97f3db35/linux-distribution-packaging-and-bitcoin.md
1856 2013-07-22 23:06:35 ielo has joined
1857 2013-07-22 23:06:46 <petertodd> gmaxwell: just separately clearsign the same document and concatenate them
1858 2013-07-22 23:07:01 <Luke-Jr> petertodd: btw, is this PGP-standard, or a GPG extension?
1859 2013-07-22 23:07:02 <gmaxwell> wow! coool!
1860 2013-07-22 23:07:39 ielo has quit (Client Quit)
1861 2013-07-22 23:07:44 <petertodd> Luke-Jr: dunno actually
1862 2013-07-22 23:07:48 <gmaxwell> Can you insert some text: e.g.  Gregory Maxwell <greg@xiph.org>:
1863 2013-07-22 23:08:00 <gmaxwell> so that you can show the names with the signatures?
1864 2013-07-22 23:08:20 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md 5d9dd4cd3787c540fcb62fb7c720105292d02d0fa8478c4ff31ae528e6aabb80
1865 2013-07-22 23:08:25 <petertodd> gmaxwell: Hmm... maybe you can have a Comment: ? I dunno, you can obvs put it in the version
1866 2013-07-22 23:08:37 handle has quit (Remote host closed the connection)
1867 2013-07-22 23:08:56 <petertodd> Luke-Jr: I can sign it later tonight
1868 2013-07-22 23:09:10 handle has joined
1869 2013-07-22 23:10:54 <Luke-Jr> gmaxwell: seems to work: https://gist.github.com/luke-jr/6058439/raw/ab8e6561efddbc6963cf20bba5a9cccdef3a19a3/linux-distribution-packaging-and-bitcoin.md
1870 2013-07-22 23:11:12 deego` is now known as deego
1871 2013-07-22 23:11:50 <petertodd> Luke-Jr: I strongly recomend wrapping it to email-length lines so we can send it around in emails
1872 2013-07-22 23:11:53 <gmaxwell> sipa: are you happy with that text?
1873 2013-07-22 23:12:01 <petertodd> Luke-Jr: I think 72 is the standard for email?
1874 2013-07-22 23:12:25 <gmaxwell> yea, it should be wrapped to 75. Use fmt.
1875 2013-07-22 23:12:33 Guest38565 has left ()
1876 2013-07-22 23:12:38 wizkid057 has quit (Read error: Connection reset by peer)
1877 2013-07-22 23:12:42 <Luke-Jr> petertodd: I don't think wrapping will make emails viable alone
1878 2013-07-22 23:13:12 <gmaxwell> Luke-Jr: no, but it shouldn't be gratitiously long.
1879 2013-07-22 23:13:25 <petertodd> Luke-Jr: point is if the line's don't get wrapped anywhere cut-n-paste generally doesn't break the signatures
1880 2013-07-22 23:13:41 <petertodd> Luke-Jr: --clearsign tolerates whitespace, but not line wrapping
1881 2013-07-22 23:14:14 <Luke-Jr> so 72 or 75?
1882 2013-07-22 23:14:15 darkee_ has joined
1883 2013-07-22 23:14:20 MCM-Mike has joined
1884 2013-07-22 23:14:24 <gmaxwell> Luke-Jr: try both?
1885 2013-07-22 23:14:35 <gmaxwell> if 72 looks okay, start that.
1886 2013-07-22 23:14:47 <Luke-Jr> I don't understand the diff between -w and -g
1887 2013-07-22 23:15:03 GordonG3kko has quit (Ping timeout: 240 seconds)
1888 2013-07-22 23:15:33 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md f8fc92dd32f6ae6065bddc9e3be3718a5922de37daf514b8d49c74a322e1126e
1889 2013-07-22 23:15:35 <petertodd> Luke-Jr: one last suggestion: s/*/_/ looks better, and leads to lines being underlined in a lot of stuff
1890 2013-07-22 23:15:58 <petertodd> Luke-Jr: *'s look less professional and more obtrusive
1891 2013-07-22 23:16:09 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md bc078c7b05a60a8c008b7b99b4599ac8110ff5b199bc9085125d1d97744d7910
1892 2013-07-22 23:17:03 nonick has quit (Ping timeout: 240 seconds)
1893 2013-07-22 23:17:04 MobiusL has quit (Ping timeout: 240 seconds)
1894 2013-07-22 23:17:20 <petertodd> Luke-Jr: oh, we should say July 22 2013
1895 2013-07-22 23:17:38 <Luke-Jr> then we'll all have to resign on July 23? :P
1896 2013-07-22 23:17:41 aXs_ has quit (Ping timeout: 240 seconds)
1897 2013-07-22 23:17:56 <gmaxwell> Can we drop the "hereby" from it?
1898 2013-07-22 23:18:09 <warren> henceforth
1899 2013-07-22 23:18:18 <gmaxwell> it's excessively pretending-to-be-formal, so if no one loves it it should just be removed as it adds nothing.
1900 2013-07-22 23:18:19 <Luke-Jr> "…the undersigned request that distributors…" ?
1901 2013-07-22 23:18:26 wizkid057 has joined
1902 2013-07-22 23:18:26 <petertodd> gmaxwell: +1
1903 2013-07-22 23:18:41 GordonG3kko has joined
1904 2013-07-22 23:18:42 <gmaxwell> Luke-Jr: or just ask either is fine with me.
1905 2013-07-22 23:18:49 <sipa> Luke-Jr: resign or re-,sign?
1906 2013-07-22 23:18:51 <petertodd> Luke-Jr: lol, nah, I think it's fine if the sigs don't strictly match the stated time
1907 2013-07-22 23:19:08 Wrenuld has quit (Ping timeout: 240 seconds)
1908 2013-07-22 23:19:09 <sipa> gmaxwell: i'll read it when i get home
1909 2013-07-22 23:19:10 Someguy123 has quit (Ping timeout: 246 seconds)
1910 2013-07-22 23:19:21 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md f815dce7aab77eb47c7b7edb26ad8cd766120421e4ab96780c2a350eb91ab5e3
1911 2013-07-22 23:19:48 realazthat has quit (Read error: Connection reset by peer)
1912 2013-07-22 23:19:52 <petertodd> Luke-Jr: s/2013 July 22
1913 2013-07-22 23:20:06 <petertodd> s/2013 July 22/July 22 2013/ please... we are humans :)
1914 2013-07-22 23:20:17 <Luke-Jr> petertodd: that's so backward!
1915 2013-07-22 23:20:18 <gmaxwell> bleh.
1916 2013-07-22 23:20:23 KillYourTV has quit (Ping timeout: 240 seconds)
1917 2013-07-22 23:20:26 <gmaxwell> 2013-07-22
1918 2013-07-22 23:20:33 <petertodd> heh, ISO has it's place when there is ambiguity, but that's not ambiguous
1919 2013-07-22 23:20:35 toffoo has joined
1920 2013-07-22 23:20:37 <petertodd> gmaxwell: +1 problem solved
1921 2013-07-22 23:20:53 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md 4b525d3557a310bda24f081087010e9492c5a2e6f455c76ead9a62f86a1d3ea4
1922 2013-07-22 23:20:59 Vinnie_win has quit (Read error: Connection reset by peer)
1923 2013-07-22 23:21:50 * Luke-Jr quickly adds the date in tonal … :p jk
1924 2013-07-22 23:22:02 <gmaxwell> not in blockheight?
1925 2013-07-22 23:22:05 <petertodd> Luke-Kr: s/packages.  In/packages. In/ <- double-spaced there
1926 2013-07-22 23:22:13 <Luke-Jr> gmaxwell: that might be interesting, if the timestamp really mattered :P
1927 2013-07-22 23:22:26 <petertodd> Oh, add the most recent blockhash to prove it was created after that date
1928 2013-07-22 23:22:29 Vinnie_win has joined
1929 2013-07-22 23:22:35 <petertodd> And then I'll timestamp it for the window!
1930 2013-07-22 23:22:35 realazthat has joined
1931 2013-07-22 23:22:35 realazthat has quit (Changing host)
1932 2013-07-22 23:22:35 realazthat has joined
1933 2013-07-22 23:22:41 * petertodd geeks out
1934 2013-07-22 23:22:49 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md a6a8d3b9c1c9db28b7ebe760fd617f1730bfb7f28ef3c1026e90cc6644a650fb
1935 2013-07-22 23:23:36 <Luke-Jr> petertodd: blockhash was serious?
1936 2013-07-22 23:23:41 <gmaxwell> we realize this is in en-gb / en-ca right?
1937 2013-07-22 23:23:48 KillYourTV has joined
1938 2013-07-22 23:23:52 <Luke-Jr> en-gb and en-ca are different?
1939 2013-07-22 23:24:00 <gmaxwell> I mean its not in en-us.
1940 2013-07-22 23:24:11 <Luke-Jr> good, let the English define the English language.
1941 2013-07-22 23:24:19 <Luke-Jr> <.<
1942 2013-07-22 23:24:26 <gmaxwell> Okay, fine with me. Satoshi used en-gb in a number of places.
1943 2013-07-22 23:24:29 <petertodd> Luke-Jr: semi-serious, heck, go for it
1944 2013-07-22 23:24:44 <Luke-Jr> petertodd: watch it get reorg'd..
1945 2013-07-22 23:24:48 <petertodd> Luke-Jr: lol
1946 2013-07-22 23:24:54 handle_ has joined
1947 2013-07-22 23:25:12 handle has quit (Remote host closed the connection)
1948 2013-07-22 23:25:38 <gmaxwell> I'd like to at least get a signoff from jgarzik and sipa (having both expressed opinions earlier) on the final text before we consider it really final.
1949 2013-07-22 23:25:42 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md 4d45fba38ac4af43765936e17daea8e96bf5f37992fd12ed1a01a12efe26c1a1
1950 2013-07-22 23:26:06 <petertodd> gmaxwell: Nice, Comment: Peter Todd <pete@petertodd.org> works in the signature
1951 2013-07-22 23:26:08 <Luke-Jr> and gavinandresen, since he hasn't even seen it yet
1952 2013-07-22 23:26:11 sserrano44 has quit (Quit: Computer has gone to sleep.)
1953 2013-07-22 23:26:15 <Luke-Jr> petertodd: I said that already :P
1954 2013-07-22 23:26:20 <petertodd> oops
1955 2013-07-22 23:26:37 <gmaxwell> petertodd: I think it would be pretty awesome if we could get a whole mob of signatures after the initial noteworthy ones.
1956 2013-07-22 23:26:53 <petertodd> Luke-Jr: hmm, put the hash just under the ==== line I think, looks better that way
1957 2013-07-22 23:26:59 <petertodd> IE date second
1958 2013-07-22 23:27:04 <gmaxwell> e.g. well known experts and then any bitcoin technical folks who want to sign it.
1959 2013-07-22 23:27:10 <petertodd> (date is obvs less important :))
1960 2013-07-22 23:27:13 <petertodd> gmaxwell: for sure
1961 2013-07-22 23:27:40 * petertodd needs to implement clearsigned timestamps in OpenTimestamps
1962 2013-07-22 23:27:47 wizkid057 has quit (Remote host closed the connection)
1963 2013-07-22 23:27:53 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md 20130722-linux-distribution-packaging-and-bitcoin.mdd898ff8654e22e648685b67705f7efdeeeefbb0dcd1efecccc7fb61864a3ddd9
1964 2013-07-22 23:27:55 <Luke-Jr> err
1965 2013-07-22 23:27:55 <petertodd> Problem is you really want to timestamp the signatures, not the document
1966 2013-07-22 23:28:05 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md d898ff8654e22e648685b67705f7efdeeeefbb0dcd1efecccc7fb61864a3ddd9
1967 2013-07-22 23:28:25 <petertodd> Luke-Jr: Hmm, I think we can drop the "Block " thing
1968 2013-07-22 23:28:30 <petertodd> Luke-Jr: just leave the hash
1969 2013-07-22 23:28:39 <petertodd> Luke-Jr: Anyone in bitcoin would understand the reference
1970 2013-07-22 23:28:47 <Luke-Jr> http://luke.dashjr.org/tmp/code/20130722-linux-distribution-packaging-and-bitcoin.md 670f1976548b400572f14fd12ca91aa9db99745c381b0e3d49bb1e89f9c289e9
1971 2013-07-22 23:29:08 Wrenuld has joined
1972 2013-07-22 23:29:18 Someguy123 has joined
1973 2013-07-22 23:29:20 sserrano44 has joined
1974 2013-07-22 23:29:49 <petertodd> Luke-Jr: ha, perfect.
1975 2013-07-22 23:29:59 aXs_ has joined
1976 2013-07-22 23:30:01 <petertodd> That I'm worrying about this stuff means the text is solid of course. :)
1977 2013-07-22 23:31:53 <Luke-Jr> :p
1978 2013-07-22 23:32:24 <petertodd> Hmm... extend the ='s to the end of the block hash. Or don't and tell the !@#$$ arts grad to shut the !@#$ up.
1979 2013-07-22 23:32:43 MiningBuddy has quit (Ping timeout: 245 seconds)
1980 2013-07-22 23:32:48 <gmaxwell> If I keep reading this I'm going to start shedpainting the text.
1981 2013-07-22 23:32:57 <gmaxwell> "and direct users to the upstream-provided binaries instead _until they
1982 2013-07-22 23:32:58 <gmaxwell> understand the"
1983 2013-07-22 23:32:59 <jgarzik> ACK 670f1976
1984 2013-07-22 23:33:03 MobiusL has joined
1985 2013-07-22 23:33:04 <gmaxwell> they is ambigious.
1986 2013-07-22 23:33:05 <Luke-Jr> http://luke.dashjr.org/tmp/code/bcpatching.png look good for Bitcoin Magazine?
1987 2013-07-22 23:33:11 wizkid057 has joined
1988 2013-07-22 23:33:18 <gmaxwell> hah.
1989 2013-07-22 23:33:22 <petertodd> gmaxwell: I'm not feeling the shade of gray I'm seeing, can we lighten it a bit?
1990 2013-07-22 23:33:30 coeus has quit (Quit: Verlassend)
1991 2013-07-22 23:33:35 <petertodd> Luke-Jr: lol
1992 2013-07-22 23:34:35 <Luke-Jr> side note: the extra newline at the end is to avoid PGP messing up markdown rendering too much
1993 2013-07-22 23:34:46 <petertodd> Luke-Jr: I noticed that, good idea
1994 2013-07-22 23:36:22 <petertodd> bbl
1995 2013-07-22 23:36:36 <phantomcircuit> side side note: i enjoy oreos
1996 2013-07-22 23:36:40 <Luke-Jr> …
1997 2013-07-22 23:36:49 <Luke-Jr> phantomcircuit: they've got some nasty chemicals in them :P
1998 2013-07-22 23:36:59 <phantomcircuit> Luke-Jr, that's what makes them so delicious
1999 2013-07-22 23:37:05 <Luke-Jr> I know :<
2000 2013-07-22 23:37:17 <gmaxwell> Luke-Jr: I've seen you drink gatoraid. :-/
2001 2013-07-22 23:37:21 <gmaxwell> No place to talk. :P
2002 2013-07-22 23:37:35 <Luke-Jr> gmaxwell: dunno what brand that stuff was, but I did check the chemicals in it!
2003 2013-07-22 23:41:46 realazthat is now known as pinkee
2004 2013-07-22 23:42:52 xire has quit (Ping timeout: 245 seconds)
2005 2013-07-22 23:43:41 xire has joined
2006 2013-07-22 23:44:57 wizkid057 has quit (Ping timeout: 245 seconds)
2007 2013-07-22 23:48:18 oru_ has left ()
2008 2013-07-22 23:48:37 oru has joined
2009 2013-07-22 23:50:05 <doublec> ahmedbodi: yes
2010 2013-07-22 23:50:12 xire has quit (Ping timeout: 264 seconds)
2011 2013-07-22 23:51:29 Application has quit (Remote host closed the connection)
2012 2013-07-22 23:52:44 wizkid057 has joined
2013 2013-07-22 23:53:57 nonick has joined
2014 2013-07-22 23:55:19 darkee_ has quit (Remote host closed the connection)
2015 2013-07-22 23:56:19 CheckDavid has quit (Quit: Leaving)
2016 2013-07-22 23:57:00 c0rw1n has joined