1 2013-01-23 00:00:18 <HM> yeah i'm being a dumbass
   2 2013-01-23 00:00:29 rdymac has quit (Ping timeout: 255 seconds)
   3 2013-01-23 00:00:38 <HM> the goto offset toolbar in Okteta was set to decimal :|
   4 2013-01-23 00:01:22 <HM> transaction format seems simple enough
   5 2013-01-23 00:04:56 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
   6 2013-01-23 00:05:22 UukGoblin has quit (Ping timeout: 252 seconds)
   7 2013-01-23 00:06:01 UukGoblin has joined
   8 2013-01-23 00:06:06 sgornick has quit (Ping timeout: 248 seconds)
   9 2013-01-23 00:06:49 gjs278 has quit (Remote host closed the connection)
  10 2013-01-23 00:07:53 agricocb has joined
  11 2013-01-23 00:09:35 legitnick1 has quit (Read error: Operation timed out)
  12 2013-01-23 00:10:16 tcatm has quit (Quit: No Ping reply in 180 seconds.)
  13 2013-01-23 00:10:37 tcatm has joined
  14 2013-01-23 00:10:39 tcatm has quit (Changing host)
  15 2013-01-23 00:10:39 tcatm has joined
  16 2013-01-23 00:18:54 t7 has quit (Quit: Konversation terminated!)
  17 2013-01-23 00:19:21 reizuki has quit (Ping timeout: 276 seconds)
  18 2013-01-23 00:20:40 gjs278 has joined
  19 2013-01-23 00:23:40 Guest55513 has joined
  20 2013-01-23 00:25:25 fiesh has quit (Ping timeout: 246 seconds)
  21 2013-01-23 00:26:29 fiesh has joined
  22 2013-01-23 00:28:42 Prattler has joined
  23 2013-01-23 00:33:20 b4epoche has quit (Read error: Operation timed out)
  24 2013-01-23 00:36:35 b4epoche has joined
  25 2013-01-23 00:38:59 Liboan has quit (Read error: Connection timed out)
  26 2013-01-23 00:39:15 Guest55513 has quit (Read error: Connection timed out)
  27 2013-01-23 00:39:39 Liboan has joined
  28 2013-01-23 00:40:04 Liboan is now known as Guest78059
  29 2013-01-23 00:40:53 torsthaldo has quit (Read error: Connection reset by peer)
  30 2013-01-23 00:42:15 Guest55513 has joined
  31 2013-01-23 00:52:00 BurtyBB is now known as BurtyB
  32 2013-01-23 00:58:18 Guest55513 has quit (Read error: Connection timed out)
  33 2013-01-23 01:06:26 petertodd has quit (Ping timeout: 245 seconds)
  34 2013-01-23 01:07:26 petertodd has joined
  35 2013-01-23 01:20:31 bitnumus has quit (Ping timeout: 248 seconds)
  36 2013-01-23 01:29:14 kaccw has joined
  37 2013-01-23 01:34:19 bitnumus has joined
  38 2013-01-23 01:37:48 owowo has quit (Quit: sayonara)
  39 2013-01-23 01:37:58 D34TH has quit (Read error: Connection reset by peer)
  40 2013-01-23 01:38:15 D34TH has joined
  41 2013-01-23 01:48:52 jrmithdobbs has quit (Quit: quit)
  42 2013-01-23 01:49:27 jrmithdobbs has joined
  43 2013-01-23 01:50:53 kaccw has quit (Quit: Page closed)
  44 2013-01-23 01:57:27 jrmithdobbs has quit (Quit: quit)
  45 2013-01-23 01:57:57 jrmithdobbs has joined
  46 2013-01-23 02:07:28 D34TH_ has joined
  47 2013-01-23 02:07:28 D34TH has quit (Read error: Connection reset by peer)
  48 2013-01-23 02:09:19 D34TH_ has quit (Read error: Connection reset by peer)
  49 2013-01-23 02:22:19 copumpkin has quit (Ping timeout: 252 seconds)
  50 2013-01-23 02:22:28 MaxSan has joined
  51 2013-01-23 02:22:55 copumpkin has joined
  52 2013-01-23 02:24:14 [7] has quit (Ping timeout: 260 seconds)
  53 2013-01-23 02:26:55 one_zero has quit (Ping timeout: 272 seconds)
  54 2013-01-23 02:42:44 Tiggr has joined
  55 2013-01-23 02:43:02 MrTiggr has quit (Read error: Connection reset by peer)
  56 2013-01-23 02:43:14 <dipho> ah, i got it
  57 2013-01-23 02:43:32 <dipho> long talk about whether to enforce block i's time to be after block i+1 's time
  58 2013-01-23 02:43:42 <dipho> *i-1
  59 2013-01-23 02:43:52 <dipho> previous block
  60 2013-01-23 02:44:29 Mr_Tiggr has joined
  61 2013-01-23 02:44:31 <dipho> well, when the miner broadcasts the newly found block, other people might reject it if it has the wrong time
  62 2013-01-23 02:44:43 <dipho> right? isn't that enough?
  63 2013-01-23 02:45:25 Tiggr has quit (Read error: Connection reset by peer)
  64 2013-01-23 02:48:37 andytoshi has joined
  65 2013-01-23 02:50:23 ambimorph has joined
  66 2013-01-23 03:03:14 swappermall has quit (Ping timeout: 256 seconds)
  67 2013-01-23 03:07:02 swappermall has joined
  68 2013-01-23 03:13:43 rdymac has joined
  69 2013-01-23 03:16:29 rdymac has quit (Remote host closed the connection)
  70 2013-01-23 03:22:14 AlexWaters has quit (Quit: Leaving.)
  71 2013-01-23 03:23:34 freakazoid has quit (Ping timeout: 246 seconds)
  72 2013-01-23 03:35:22 <dipho> i am not laughing at this gmaxwell, sorry
  73 2013-01-23 03:35:45 <dipho> i don't share your sense of humor
  74 2013-01-23 03:36:10 <Luke-Jr> …
  75 2013-01-23 03:36:56 <SomeoneWeird> >.<
  76 2013-01-23 03:40:50 iwoter has joined
  77 2013-01-23 03:43:32 JZavala has joined
  78 2013-01-23 03:50:06 fiesh has quit (Ping timeout: 248 seconds)
  79 2013-01-23 03:53:37 fiesh has joined
  80 2013-01-23 03:54:51 Silverion has quit (Remote host closed the connection)
  81 2013-01-23 03:56:40 emryss has joined
  82 2013-01-23 03:57:27 paraipan has joined
  83 2013-01-23 03:59:46 <swappermall> when bitcoin-qt connects with, say 8, internet connections, what is my exposure to the risk that someone can snoop on my server and find my wallet?
  84 2013-01-23 04:00:09 <swappermall> and can I do anything to eliminate this risk?
  85 2013-01-23 04:02:02 <gavinandresen> swappermall: bitcoin-qt's networking code has been extensively reviewed. There is a risk there is some bug lurking there that would let a hacker get in to your machine, but we work really hard to make that risk really small.
  86 2013-01-23 04:02:53 <gavinandresen> swappermall: if you want to mitigate that risk, then run two servers-- one with a bitcoind that connects to everybody but has no wallet.  And another that connects ONLY to the first.
  87 2013-01-23 04:03:44 <swappermall> thank you for that assessment gavinandresen ... that strategy makes a lot of sense to me
  88 2013-01-23 04:04:40 <gavinandresen> swappermall: you'll want to run intrusion detection software on that first, connected-to-everybody server.  And for both servers basic security hygiene is a must.
  89 2013-01-23 04:05:19 <swappermall> can you suggest a good intrusion detection software for Ubuntu?
  90 2013-01-23 04:05:33 <gavinandresen> nope, not my area of expertise.
  91 2013-01-23 04:05:48 <swappermall> ok
  92 2013-01-23 04:08:30 AtashiCon has quit (Quit: AtashiCon)
  93 2013-01-23 04:08:58 emryss has quit (Remote host closed the connection)
  94 2013-01-23 04:10:07 emryss has joined
  95 2013-01-23 04:10:39 AtashiCon has joined
  96 2013-01-23 04:10:48 Mr_Tiggr has quit (Quit: bainow)
  97 2013-01-23 04:12:29 sbbodhtimrj has joined
  98 2013-01-23 04:16:49 jrmithdobbs has quit (Quit: quit)
  99 2013-01-23 04:16:50 sbbodhtimrj is now known as jrmithdobbs
 100 2013-01-23 04:18:10 one_zero has joined
 101 2013-01-23 04:18:33 ambimorph has quit (Ping timeout: 276 seconds)
 102 2013-01-23 04:19:02 <swappermall> is there a sample bitcoin.conf file that illustrates how Server A, fromlocalhost:8332, can connect using the SSL protocol with Server B?
 103 2013-01-23 04:19:18 CodeShark has joined
 104 2013-01-23 04:20:58 <swappermall> ah en.bitcoin.it/wiki/Bitcoin-js-remote
 105 2013-01-23 04:22:04 <gavinandresen> swappermall: SSL?  you don't need SSL.   just connect=ip.address.of.server  and listen=0  in the bitcoin.conf on server2
 106 2013-01-23 04:24:05 one_zero has quit (Read error: Connection reset by peer)
 107 2013-01-23 04:26:02 <swappermall> so the line command is bitcoind --connect=[ip,address.of.serverA] and bitcoin.conf on serverA has one line 'listen=0'?
 108 2013-01-23 04:27:14 one_zero has joined
 109 2013-01-23 04:27:48 <swappermall> *ip.address
 110 2013-01-23 04:28:25 juchmis has quit (Read error: Connection reset by peer)
 111 2013-01-23 04:29:18 juchmis has joined
 112 2013-01-23 04:30:30 one_zero has quit (Read error: Connection reset by peer)
 113 2013-01-23 04:30:34 <gavinandresen> no, bitcoind -connect=ip.address.of.server.a -listen=0
 114 2013-01-23 04:30:54 <gavinandresen> you want the server with the wallet to ONLY connect, and not listen for incoming connections.
 115 2013-01-23 04:31:01 <gavinandresen> (only connect out)
 116 2013-01-23 04:31:49 Seeraber has joined
 117 2013-01-23 04:32:51 <Seeraber> hi all, I am looking for a good sample game-of-chance platform, or someone selling their site?
 118 2013-01-23 04:34:17 one_zero has joined
 119 2013-01-23 04:35:35 Hasimir is now known as GoldFingering
 120 2013-01-23 04:36:44 <CodeShark> gavinandresen: you need SSL to prevent man-in-the-middle attacks
 121 2013-01-23 04:38:43 <gavinandresen> CodeShark: I may be wrong (I often am), but last time I checked a direct TCP connection to an IP address is really hard to MITM.
 122 2013-01-23 04:38:55 <gavinandresen> Unless one of the ISPs is the man in the middle.
 123 2013-01-23 04:39:13 <BlueMatt> or they are on the same lan
 124 2013-01-23 04:40:15 <petertodd> apt-get install mitmproxy on ubuntu and debian...
 125 2013-01-23 04:40:37 <petertodd> "features: make scripted changes to HTTP traffic using Python, SSL interception certs generated on the fly"
 126 2013-01-23 04:41:08 <gavinandresen> we're talking bitcoin-protocol, not HTTP though
 127 2013-01-23 04:41:10 loltu has quit (Excess Flood)
 128 2013-01-23 04:41:18 <CodeShark> for RPC, bitcoind already supports SSL
 129 2013-01-23 04:41:30 <gavinandresen> I suppose if you're REALLY paranoid you could ssh-tunnel port 8333
 130 2013-01-23 04:41:35 <petertodd> gavin: right, although that'll actually make the job easier
 131 2013-01-23 04:41:41 <Seeraber> anybody have some link to a step by step or VM image or amazon instance for say a simple coin flip -- I want to work on WebGl game
 132 2013-01-23 04:41:50 <petertodd> gavin: actually that's a really good idea, ssh tunnels are dead easy to setup
 133 2013-01-23 04:42:19 loltu has joined
 134 2013-01-23 04:44:51 paraipan has quit (Quit: Saliendo)
 135 2013-01-23 04:44:59 GoldFingering is now known as Mephistopheles
 136 2013-01-23 04:46:04 Fallensworth has joined
 137 2013-01-23 04:47:29 one_zero has quit (Read error: Connection reset by peer)
 138 2013-01-23 04:48:13 yinqu has joined
 139 2013-01-23 04:48:50 b4epoche has quit (Ping timeout: 255 seconds)
 140 2013-01-23 04:49:36 <CodeShark> launching a MITM attack on this type of setup is in fact not so simple and only of limited use - but setting up an ssh tunnel isn't too difficult
 141 2013-01-23 04:50:03 <CodeShark> the wallet node is still doing block verification
 142 2013-01-23 04:50:22 <CodeShark> the attack could cause it to not hear of blocks or transactions
 143 2013-01-23 04:50:24 <CodeShark> but that's about it
 144 2013-01-23 04:50:45 <CodeShark> could get it to accept a shorter chain as official
 145 2013-01-23 04:51:56 <CodeShark> it's easy to see if it's been compromised by looking at the blockcount and the mempool
 146 2013-01-23 04:52:44 b4epoche has joined
 147 2013-01-23 04:53:31 yinqu has quit (Quit: Page closed)
 148 2013-01-23 04:53:35 <petertodd> well, remember that all a MITM attack can do, is open up the original poster to a theoretical remote exploit that he's trying to avoid with the two node setup
 149 2013-01-23 04:54:08 one_zero has joined
 150 2013-01-23 04:54:10 one_zero has quit (Read error: Connection reset by peer)
 151 2013-01-23 04:54:31 one_zero has joined
 152 2013-01-23 04:55:34 <CodeShark> you mean some unknown vulnerability in the way bitcoind manages peers?
 153 2013-01-23 04:56:06 <petertodd> exactly, that's what he's trying to avoid, so avoiding MITM's is being fairly paranoid
 154 2013-01-23 04:57:02 <petertodd> I should have been more clear that I meant the fact that mitmproxy does all the stuff it does, means ripping out the http part and replacing it with a custom bitcoind exploit would be pretty easy (it's python)
 155 2013-01-23 04:57:27 one_zero has quit (Read error: Connection reset by peer)
 156 2013-01-23 04:57:39 <petertodd> assuming such exploit existed of course!
 157 2013-01-23 04:58:51 <CodeShark> HTTP is just TCP with special headers :P
 158 2013-01-23 04:59:15 <petertodd> ha, exactly
 159 2013-01-23 05:00:34 <petertodd> I'm actually kinda surprised I couldn't find a "generic tcp man-in-the-middle" package; the h@x0rz aren't showing good modular programming...
 160 2013-01-23 05:00:36 techlife has joined
 161 2013-01-23 05:01:17 LargoG has quit (Remote host closed the connection)
 162 2013-01-23 05:01:29 one_zero has joined
 163 2013-01-23 05:02:32 ambimorph has joined
 164 2013-01-23 05:04:48 one_zero has quit (Read error: Connection reset by peer)
 165 2013-01-23 05:10:07 ambimorph has quit (Ping timeout: 240 seconds)
 166 2013-01-23 05:10:12 one_zero has joined
 167 2013-01-23 05:10:34 ambimorph has joined
 168 2013-01-23 05:11:46 Seeraber is now known as Seeraber|away
 169 2013-01-23 05:21:37 Fallensworth has quit (Ping timeout: 240 seconds)
 170 2013-01-23 05:23:20 <CodeShark> what are the earliest versions of debian and ubuntu that come with lsb_release?
 171 2013-01-23 05:23:35 one_zero has quit (Read error: Connection reset by peer)
 172 2013-01-23 05:26:18 ambimorph has quit (Ping timeout: 256 seconds)
 173 2013-01-23 05:28:43 one_zero has joined
 174 2013-01-23 05:31:38 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 175 2013-01-23 05:33:49 one_zero has quit (Read error: Connection reset by peer)
 176 2013-01-23 05:36:08 one_zero has joined
 177 2013-01-23 05:39:44 <Luke-Jr> CodeShark: do they now? LSB requires RPM
 178 2013-01-23 05:40:12 <CodeShark> I've tested that command from both squeeze and precise and it works fine
 179 2013-01-23 05:40:35 <CodeShark> doesn't work on gentoo
 180 2013-01-23 05:40:40 ambimorph has joined
 181 2013-01-23 05:40:50 <SomeoneWeird> Luke-Jr, they have for a long time
 182 2013-01-23 05:41:26 <Luke-Jr> CodeShark: it might if you install lsb-release, but most people probably don't.
 183 2013-01-23 05:41:40 <CodeShark> I never explicitly installed it on either
 184 2013-01-23 05:41:59 <SomeoneWeird> it's installed by default on ubuntu/debian
 185 2013-01-23 05:42:08 <CodeShark> yeah
 186 2013-01-23 05:42:47 <CodeShark> I'm trying to find something comparable in gentoo
 187 2013-01-23 05:43:22 <CodeShark> just an easy way of obtaining the distro id and release version
 188 2013-01-23 05:44:09 brwyatt is now known as brwyatt|Away
 189 2013-01-23 05:50:29 RainbowDashh has joined
 190 2013-01-23 05:52:45 dust-otc has joined
 191 2013-01-23 05:55:15 ambimorph has quit (Ping timeout: 244 seconds)
 192 2013-01-23 05:55:56 valparaiso has joined
 193 2013-01-23 06:04:46 <Luke-Jr> CodeShark: Gentoo doesn't have releases
 194 2013-01-23 06:05:05 <Luke-Jr> but /etc/gentoo-release has the version of the baselayout pkg
 195 2013-01-23 06:05:20 <CodeShark> ok
 196 2013-01-23 06:13:57 <CodeShark> Luke-Jr: you were saying yesterday that makefile.unix for bitcoin/bitcoin doesn't work on your gentoo
 197 2013-01-23 06:14:03 <CodeShark> what are the issues?
 198 2013-01-23 06:14:57 ovidiusoft has joined
 199 2013-01-23 06:17:54 <Luke-Jr> CodeShark: you just need to pass BDB_INCLUDE_PATH=/usr/include/db4.8
 200 2013-01-23 06:18:09 <CodeShark> ok - that's what I thought
 201 2013-01-23 06:18:52 <CodeShark> the configure script should now work on your gentoo, then
 202 2013-01-23 06:20:42 <Seeraber> anybody using libcoin?
 203 2013-01-23 06:37:04 andytoshi has quit (Remote host closed the connection)
 204 2013-01-23 06:38:01 andytoshi has joined
 205 2013-01-23 06:50:01 FredEE has quit (Quit: FredEE)
 206 2013-01-23 06:50:32 RazielZ has joined
 207 2013-01-23 06:51:10 FredEE has joined
 208 2013-01-23 06:57:08 one_zero has quit (Read error: Connection reset by peer)
 209 2013-01-23 06:59:20 osmosis has quit (Quit: Leaving)
 210 2013-01-23 06:59:29 one_zero has joined
 211 2013-01-23 07:02:07 JZavala has quit (Ping timeout: 240 seconds)
 212 2013-01-23 07:03:33 setkeh has quit (Ping timeout: 264 seconds)
 213 2013-01-23 07:03:40 setkeh has joined
 214 2013-01-23 07:06:41 mariusursache has joined
 215 2013-01-23 07:06:48 FredEE has quit (Quit: FredEE)
 216 2013-01-23 07:07:35 root2 has quit (Ping timeout: 244 seconds)
 217 2013-01-23 07:09:01 bk128 has joined
 218 2013-01-23 07:09:22 jrmithdobbs has quit (Quit: ZNC - http://znc.in)
 219 2013-01-23 07:10:52 jrmithdobbs has joined
 220 2013-01-23 07:16:31 zebedee_ has joined
 221 2013-01-23 07:23:48 iwoter has quit (Ping timeout: 276 seconds)
 222 2013-01-23 07:24:41 <muhoo> how would one create a new address for an existing private key in bitcoinj?
 223 2013-01-23 07:24:58 <muhoo> i see how to create an address object from a hash, that's not what i'm asking.
 224 2013-01-23 07:25:55 <muhoo> i've got ECKey object, attached to a wallet, that's great. but now i'm wondering how to generate new keys for it, as one would do in the c++ client
 225 2013-01-23 07:27:39 <gmaxwell> muhoo: a private key has only one address.
 226 2013-01-23 07:27:58 <muhoo> that's not what i see in the c++ client
 227 2013-01-23 07:27:59 <gmaxwell> (well two if you count the compressed form, but the compressed flag should be considered a properity of the private key)
 228 2013-01-23 07:28:13 <muhoo> i can easily generate a bunch of addresses from one private key
 229 2013-01-23 07:28:16 <gmaxwell> muhoo: Get your glasses fixed?
 230 2013-01-23 07:28:22 <gmaxwell> :P
 231 2013-01-23 07:28:36 <gmaxwell> muhoo: you cannot, I'm not sure what you're misunderstanding there though.
 232 2013-01-23 07:29:18 <CodeShark> you can use a CKey object to generate a bunch of keys - but each one has a distinct private key
 233 2013-01-23 07:29:22 <CodeShark> *is
 234 2013-01-23 07:30:24 <muhoo> why does dumpprivkey for a whole bunch of addresses in a wallet come up with the exact same private key?
 235 2013-01-23 07:30:48 <muhoo> i've done this, several times. what am i mis-seeing? it's the same value.
 236 2013-01-23 07:30:56 <CodeShark> that should not happen
 237 2013-01-23 07:32:40 Mephistopheles is now known as Hasimir
 238 2013-01-23 07:32:43 <CodeShark> either 1) you're not entering the command right, 2) you're using a bad build, 3) you seriously need glasses
 239 2013-01-23 07:33:31 <gmaxwell> muhoo: when you figure it out, please let us know- I'm curious.
 240 2013-01-23 07:35:17 <muhoo> hmm. maybe the addresses weren't generated from getnewaddress, but rather from transactions
 241 2013-01-23 07:35:28 <CodeShark> ?
 242 2013-01-23 07:35:51 <CodeShark> you can only dump private keys that were generated in that wallet or imported into it
 243 2013-01-23 07:36:22 <muhoo> i have to look, but i'm pretty sure that bitcoind has generated new addresses after each transaction
 244 2013-01-23 07:36:30 <CodeShark> change addresses?
 245 2013-01-23 07:36:36 <muhoo> possibly
 246 2013-01-23 07:36:53 <muhoo> and, i'm damn sure they have the same privkey
 247 2013-01-23 07:37:22 <muhoo> but indeed, i just tested it, and getnewaddress does indeed create a new privkey, so i definitely had that wrong
 248 2013-01-23 07:38:29 <gmaxwell> muhoo: what you're describing is impossible- perhaps some insane bug, but I don't even see how... the only addresses you see in listtransactions are your recieve addresses... which will all have distinct private keys.
 249 2013-01-23 07:38:53 <muhoo> so it would not be surprising if getaddressesbyaccount listed a bunch of addresses that were change addresses and all had the same privkey?
 250 2013-01-23 07:39:17 <gmaxwell> yes, it would be surprising — since its a mathmatical impossiblity.
 251 2013-01-23 07:39:58 <gmaxwell> (getaddressesbyaccount also does not list change addresses)
 252 2013-01-23 07:40:07 FredEE has joined
 253 2013-01-23 07:40:09 <muhoo>  i should pull up the wallet i have which displays this behavior. it has real coins in it so i can't send it to anyone to see though.
 254 2013-01-23 07:40:28 grau has joined
 255 2013-01-23 07:40:32 <muhoo> i'm on a test network trying to duplicate what i saw, and can't.
 256 2013-01-23 07:41:10 <gmaxwell> You should go try to duplicate it in your wallet. even if you can't share it you could at least reproduce and tell me exactly what you were doing
 257 2013-01-23 07:41:17 grau has quit (Remote host closed the connection)
 258 2013-01-23 07:41:22 <muhoo> fair enough, will do.
 259 2013-01-23 07:44:16 meLon has quit (Read error: Operation timed out)
 260 2013-01-23 07:45:27 meLon has joined
 261 2013-01-23 07:47:31 BTCOxygen has joined
 262 2013-01-23 07:51:03 bk128 has quit (Quit: bk128)
 263 2013-01-23 07:51:23 <slush> Hi, do you know any moderator of "Project development" board of bitcointalk?
 264 2013-01-23 07:52:02 <slush> There's no moderator mentioned on forums listing...
 265 2013-01-23 07:53:31 reizuki has joined
 266 2013-01-23 07:53:31 reizuki has quit (Changing host)
 267 2013-01-23 07:53:31 reizuki has joined
 268 2013-01-23 07:53:39 Seeraber is now known as Seeraber|away
 269 2013-01-23 07:54:11 <gmaxwell> slush: the global moderators.
 270 2013-01-23 07:55:23 <slush> gmaxwell: so...?
 271 2013-01-23 07:57:00 safra has joined
 272 2013-01-23 07:57:26 <slush> gmaxwell: who's global moderator? I once wrote to Theymos, he respond after two months...
 273 2013-01-23 07:57:34 <gmaxwell> anyone with global moderator under their name. maged theymos johnthedong
 274 2013-01-23 07:57:47 root2 has joined
 275 2013-01-23 07:57:48 <slush> gmaxwell: thanks
 276 2013-01-23 07:59:16 porquilho has joined
 277 2013-01-23 07:59:59 <CodeShark> people with usernames like johnthedong shouldn't be moderators :p
 278 2013-01-23 08:01:21 <gmaxwell> CodeShark: uh. you have a problem with chinese people?
 279 2013-01-23 08:01:46 <CodeShark> gmaxwell: chinese people don't use articles like "the" nor silent letters like "h"
 280 2013-01-23 08:02:28 <CodeShark> xiandong or zhiangdong would be chinese
 281 2013-01-23 08:02:32 <gmaxwell> I believe he's actually chinese and John is an anglified first name... he speaks chinese at least.
 282 2013-01-23 08:03:45 <gmaxwell> There are lots of things to complain about wrt that forum- his name isn't really one of them.
 283 2013-01-23 08:04:03 <CodeShark> johnthedong is a B-class porn star :p
 284 2013-01-23 08:04:37 <gmaxwell> hah. His posts are all non-porn boring stuff.
 285 2013-01-23 08:08:32 bitafterbit has joined
 286 2013-01-23 08:09:27 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 287 2013-01-23 08:11:34 CodesInChaos has joined
 288 2013-01-23 08:11:36 swappermall_ has quit (Ping timeout: 256 seconds)
 289 2013-01-23 08:14:43 <weex> if i import a private key with importprivkey, it's never used for change right?
 290 2013-01-23 08:16:01 jdnavarro has joined
 291 2013-01-23 08:16:59 toffoo has quit ()
 292 2013-01-23 08:17:33 iwoter1 has joined
 293 2013-01-23 08:17:43 grau has joined
 294 2013-01-23 08:21:17 da2ce7_d is now known as da2ce7
 295 2013-01-23 08:25:53 grau has quit (Remote host closed the connection)
 296 2013-01-23 08:26:12 bitafterbit has quit (Remote host closed the connection)
 297 2013-01-23 08:27:42 yareyare has joined
 298 2013-01-23 08:29:28 one_zero has quit (Read error: Connection reset by peer)
 299 2013-01-23 08:33:16 Hasimir- has joined
 300 2013-01-23 08:35:37 Hasimir has quit (Ping timeout: 240 seconds)
 301 2013-01-23 08:40:03 pusle has joined
 302 2013-01-23 08:44:21 FredEE has quit (Quit: FredEE)
 303 2013-01-23 08:45:10 <CodeShark> weex: right
 304 2013-01-23 08:48:33 <CodeShark> unless it just so happens to be the same as a key in your wallet's pool
 305 2013-01-23 08:53:03 RainbowDashh has quit (Read error: Connection reset by peer)
 306 2013-01-23 08:54:22 <muhoo> hmm, will have to wait until tomorrow until the chain downloads so i can verify that same-privkey behavior
 307 2013-01-23 08:54:28 <muhoo> but i found this in docs "getaccountaddress will return the same address until coins are received on that address; once coins have been received, it will generate and return a new address. "
 308 2013-01-23 08:54:32 <muhoo> https://en.bitcoin.it/wiki/Accounts_explained
 309 2013-01-23 08:54:57 <muhoo> which is indeed what i saw. and that new address generated is what had the same privkey as the others in the wallet
 310 2013-01-23 08:55:29 bk128 has joined
 311 2013-01-23 08:58:47 <muhoo> but every other doc i've found implies that is impossible
 312 2013-01-23 08:59:40 <sipa> two different addresses for one account is possible
 313 2013-01-23 08:59:45 <muhoo> including the code for ECKey. it's injective
 314 2013-01-23 09:00:23 <sipa> two different private keys wit the same address is extremely unlikely
 315 2013-01-23 09:00:30 <muhoo> right, but i saw every address in the account having the same result from dumpprivkey
 316 2013-01-23 09:00:35 <sipa> what OS are you on?
 317 2013-01-23 09:00:39 <muhoo> which, seems impossible
 318 2013-01-23 09:00:41 <muhoo> linux
 319 2013-01-23 09:00:53 <sipa> more specific?
 320 2013-01-23 09:01:05 UukGoblin has quit (Changing host)
 321 2013-01-23 09:01:05 UukGoblin has joined
 322 2013-01-23 09:01:09 <muhoo> debian wheezy, debian squeeze
 323 2013-01-23 09:01:31 <sipa> if your RNG is broken, i suppose you can end up with the same privkey every time
 324 2013-01-23 09:01:50 <sipa> but then the addresses should be the same as well
 325 2013-01-23 09:02:07 <muhoo> ah, well that's not the case. and /dev/urandom and /dev/random both seem to be working
 326 2013-01-23 09:02:12 <muhoo> ssh and ssl also seem to work
 327 2013-01-23 09:02:32 <sipa> can you paste the exact commands you execute somewhere (excluding the actual privkeys outputted, of course)
 328 2013-01-23 09:02:52 <muhoo> i will, probably tomorrow though once the chain catches up
 329 2013-01-23 09:03:04 <muhoo> bitcoind takes minutes to respond to simple commands until the chain is caught up.
 330 2013-01-23 09:03:32 <sipa> eh.. ok
 331 2013-01-23 09:03:35 <muhoo> i'm on december 5th at the moment
 332 2013-01-23 09:04:09 <porquilho> http://cir.ca/story/ira-isaacs-sentenced/all
 333 2013-01-23 09:04:50 b4epoche has quit (Ping timeout: 246 seconds)
 334 2013-01-23 09:05:26 <muhoo> no big deal, i'll carry on with what i was doing assuming that keypairs are, uh,  pairs.
 335 2013-01-23 09:05:57 <CodeShark> actually, keypair is not strictly correct - the public key is generated from the private key
 336 2013-01-23 09:06:11 <CodeShark> the private key contains all the information in it to generate the public key
 337 2013-01-23 09:06:58 <CodeShark> and a bitcoin address is a hash of that public key
 338 2013-01-23 09:07:21 <muhoo> it looks like it takes the privkey and the network params, correct?
 339 2013-01-23 09:07:57 b4epoche has joined
 340 2013-01-23 09:09:15 dinox_ has quit (Changing host)
 341 2013-01-23 09:09:15 dinox_ has joined
 342 2013-01-23 09:11:02 t7 has joined
 343 2013-01-23 09:11:32 <CodeShark> by network params, you mean the version byte?
 344 2013-01-23 09:12:48 dinox_ is now known as dinox
 345 2013-01-23 09:13:30 <porquilho> http://arstechnica.com/business/2013/01/bitcoin-based-casino-rakes-in-over-500000-profit-in-six-months/
 346 2013-01-23 09:13:48 <t7> holy moly
 347 2013-01-23 09:15:34 swappermall has quit (Read error: Connection reset by peer)
 348 2013-01-23 09:17:24 <CodeShark> the IRS might become interested in this :)
 349 2013-01-23 09:20:43 <muhoo> 2 coins, 1 auditor
 350 2013-01-23 09:22:29 <muhoo> there's a disturbing trend of prosecutors circumventing the "double jeopardy" clause by aggressively retrying cases. http://www.teanotprison.com/about-oshan/
 351 2013-01-23 09:23:44 <muhoo> you can just keep draining the defendendant of money till he basically gives up or can't pay laywers anymore.
 352 2013-01-23 09:23:55 <CodeShark> what were the charges in this case?
 353 2013-01-23 09:24:05 <CodeShark> the article doesn't seem to say
 354 2013-01-23 09:24:42 <CodeShark> oh, distributing LSD and MDMA?
 355 2013-01-23 09:26:35 <muhoo> some kind of psychedelics, it says
 356 2013-01-23 09:40:34 kicek has quit (Quit: Leaving)
 357 2013-01-23 09:42:42 <HM> forget the casino profits
 358 2013-01-23 09:42:54 <HM> how did a bitcoin company score $500k in venture capital
 359 2013-01-23 09:43:32 <gmaxwell> The above discussion might be better in #bitcoin
 360 2013-01-23 09:43:42 <HM> sorry
 361 2013-01-23 09:44:48 <gmaxwell> No biggie, I'm as guilty of the [ot] talk as anyone.
 362 2013-01-23 09:45:25 <muhoo> it's not too far adrift anyway, as i'm sure there are people doing bitcoind-dev in search of making a profit, with or without vc
 363 2013-01-23 09:48:50 dNetGuru has joined
 364 2013-01-23 09:49:19 dNetGuru has left ()
 365 2013-01-23 09:50:58 <HM> Well a lot of entrepreneurs will have to develop infrastructure to make a go of Bitcoin
 366 2013-01-23 09:53:33 Hasimir- is now known as Hasimir
 367 2013-01-23 09:53:33 Hasimir has quit (Changing host)
 368 2013-01-23 09:53:33 Hasimir has joined
 369 2013-01-23 09:54:58 <HM> Anyone here using libbitcoin?
 370 2013-01-23 09:55:30 <HM> Any brief thoughts or concerns with it welcome
 371 2013-01-23 09:56:42 <sipa> not sure it's still maintained
 372 2013-01-23 09:57:15 <HM> it seems to be
 373 2013-01-23 09:57:18 <HM> moved to github
 374 2013-01-23 09:57:38 <HM> https://github.com/spesmilo/libbitcoin/commits/master
 375 2013-01-23 09:58:13 <sipa> oh yes
 376 2013-01-23 09:59:09 <HM> not sure why protobufs is needed for BDB support
 377 2013-01-23 09:59:39 <HM> i like the code though
 378 2013-01-23 10:00:00 <HM> so was just curious if anyone knew of any issues with it
 379 2013-01-23 10:01:15 TheSeven has joined
 380 2013-01-23 10:14:17 terryww has quit (Ping timeout: 255 seconds)
 381 2013-01-23 10:19:13 Mikej0h has joined
 382 2013-01-23 10:19:25 <Mikej0h> does anybody know when I use the -addnode option in the config (many servers), I show up less on blockchain, while without I'm on it almost always?
 383 2013-01-23 10:19:38 <Mikej0h> i would expect that with -connect, but not with -addnode
 384 2013-01-23 10:20:25 <sipa> that's unexpected, but are you sure it's not just random variation?
 385 2013-01-23 10:20:46 <Mikej0h> noted it for a few days, few days with, few days without
 386 2013-01-23 10:21:13 <Mikej0h> or does the -addnode describe where to relay transactions to (coz then it would be logical)?
 387 2013-01-23 10:21:15 B0g4r7 has quit (Ping timeout: 276 seconds)
 388 2013-01-23 10:21:23 tttt1 has joined
 389 2013-01-23 10:21:27 tttt1 has left ()
 390 2013-01-23 10:21:50 <sipa> Mikej0h: not at all
 391 2013-01-23 10:21:58 tttt1 has joined
 392 2013-01-23 10:22:06 <Mikej0h> what i did, in my config I added all fallback nodes (as listed in some wiki) with addnode
 393 2013-01-23 10:22:13 <Mikej0h> didn't show up @ blockchain
 394 2013-01-23 10:22:34 <Mikej0h> removed the addnodes in config, day later i'm in blockchain
 395 2013-01-23 10:22:40 <sipa> well if you add 8 fallback nodes, the client won't do any random out connects
 396 2013-01-23 10:22:43 <Mikej0h> (didn't show up was after a week)
 397 2013-01-23 10:23:01 <sipa> while otherwise it may end up connecting to blockchain randomly
 398 2013-01-23 10:23:11 <sipa> but i think the chance for blockchain connecting to you is much higher
 399 2013-01-23 10:23:19 <sipa> and that is unaffected by addnode
 400 2013-01-23 10:23:19 <Mikej0h> mmm
 401 2013-01-23 10:23:28 <Mikej0h> strange
 402 2013-01-23 10:24:26 <Mikej0h> I wanna be @ blockchain, because I love stats :)
 403 2013-01-23 10:26:05 cosurgi has joined
 404 2013-01-23 10:26:18 B0g4r7 has joined
 405 2013-01-23 10:26:22 <Mikej0h> any suggestions how I could bitcoind spit out graphs or something?
 406 2013-01-23 10:26:46 <Mikej0h> of what it did, was is the current status (clients connected) and so on
 407 2013-01-23 10:27:06 iwoter1 is now known as iwoter
 408 2013-01-23 10:27:54 <Mikej0h> because now it's pretty much a blackbox (running from source)
 409 2013-01-23 10:28:15 kicek has joined
 410 2013-01-23 10:29:31 <lianj> what is a hash_type 131?
 411 2013-01-23 10:31:31 ciphermonk has joined
 412 2013-01-23 10:33:06 <CodeShark> it's the hash_type that comes after hash_type 130 but before hash_type 132
 413 2013-01-23 10:34:33 <lianj> CodeShark: there is no 131, at least on the wiki
 414 2013-01-23 10:35:07 <HM> 131 = 0x80 | 0x03
 415 2013-01-23 10:35:17 <HM> SIGHASH_ANYONECANPAY | SIGHASH_SINGLE
 416 2013-01-23 10:35:25 <HM> https://github.com/bitcoin/bitcoin/blob/master/src/script.h#L20
 417 2013-01-23 10:35:45 <lianj> HM: ah, thanks!
 418 2013-01-23 10:38:22 tttt1 has left ()
 419 2013-01-23 10:38:26 drizztbsd has joined
 420 2013-01-23 10:39:14 <HM> I have no idea if SIGHASH_SINGLE make sense atm
 421 2013-01-23 10:39:22 <HM> since sequence numbers aren't terribly useful
 422 2013-01-23 10:39:26 tttt1 has joined
 423 2013-01-23 10:40:08 <lianj> trying to validate this one, http://blockexplorer.com/tx/7208e5edf525f04e705fb3390194e316205b8f995c8c9fcd8c6093abe04fa27d
 424 2013-01-23 10:41:39 tttt1 has left ()
 425 2013-01-23 10:46:22 <HM> lianj: i went through a raw tranny yesterday
 426 2013-01-23 10:46:38 <HM> https://en.bitcoin.it/wiki/File:TxBinaryMap.png <-- this is the most helpful diagram imho
 427 2013-01-23 10:47:13 <MC-Eeepc> raw....tranny?
 428 2013-01-23 10:47:26 <HM> transformers, transisters, transactions...all trannies to me
 429 2013-01-23 10:47:27 <HM> :P
 430 2013-01-23 10:47:45 <MC-Eeepc> check your privilege!
 431 2013-01-23 10:48:27 MaxSan has quit (Quit: Leaving.)
 432 2013-01-23 10:55:26 <HM> I don't know what that means
 433 2013-01-23 10:56:36 <MC-Eeepc> dont worry, no one does
 434 2013-01-23 11:02:50 tttt1 has joined
 435 2013-01-23 11:07:19 Seeraber is now known as Seeraber|away
 436 2013-01-23 11:10:47 <lianj> HM: yay, works
 437 2013-01-23 11:10:57 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 438 2013-01-23 11:11:01 dvide has quit ()
 439 2013-01-23 11:17:34 terryww has joined
 440 2013-01-23 11:19:47 <da2ce7> what is the most simple what to include a constant in the bitcoin transaction script?
 441 2013-01-23 11:20:02 Scrat_o has joined
 442 2013-01-23 11:20:05 <da2ce7> aka a bitcoin address, that defines a constant?
 443 2013-01-23 11:20:47 Scrat has quit (Ping timeout: 252 seconds)
 444 2013-01-23 11:22:26 rdponticelli has quit (Remote host closed the connection)
 445 2013-01-23 11:24:32 Scrat_o is now known as Scrat
 446 2013-01-23 11:27:53 rdponticelli has joined
 447 2013-01-23 11:32:45 Garr255 has quit (Read error: Connection reset by peer)
 448 2013-01-23 11:37:33 <sipa> da2ce7: a constant?
 449 2013-01-23 11:39:59 Seeraber is now known as Seeraber|away
 450 2013-01-23 11:40:02 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 451 2013-01-23 11:43:12 <CodeShark> a bitcoin address is actually a base58check encoded public key hash - the key hash can be any arbitrary 20 bytes
 452 2013-01-23 11:43:35 <HM> it took me a while to grok the fact that there's really no such thing as a 'wallet' per se
 453 2013-01-23 11:43:45 <HM> just transactions linked other transactions
 454 2013-01-23 11:44:15 <HM> i guess the wallet is thew database side/client security side of things
 455 2013-01-23 11:44:27 <sipa> a wallet is mostly a collection of keys and transactions
 456 2013-01-23 11:44:48 <CodeShark> and a grouping of keys by label (account)
 457 2013-01-23 11:47:29 <CodeShark> but yes, you can encode constants using addresses - i.e. http://blockchain.info/tx/80ddf2e7e04922e2cbf6e744dbf47aec02d781505d8b2c4ee5f725b8882ddb2d
 458 2013-01-23 11:47:55 pusle has quit (Read error: Connection reset by peer)
 459 2013-01-23 11:47:57 tusle has joined
 460 2013-01-23 11:48:14 <da2ce7> sipa: what happens I want to put an arbitrary 1kb of data into a BitcoinAddress script.  It just gets droped.
 461 2013-01-23 11:48:14 <CodeShark> specifically the second output script
 462 2013-01-23 11:48:52 <CodeShark> if you don't care about being able to redeem it, it's a lot easier to do :)
 463 2013-01-23 11:49:04 <sipa> da2ce7: a bitcoin address is a template for a particular script
 464 2013-01-23 11:49:14 <sipa> da2ce7: and not every base58 encoded string is an address
 465 2013-01-23 11:49:17 bk128 has quit (Quit: bk128)
 466 2013-01-23 11:49:44 <CodeShark> any base58encoded 20 byte number is a valid address
 467 2013-01-23 11:50:04 <sipa> no, it needs a version byte in front
 468 2013-01-23 11:50:13 <CodeShark> I was implying that
 469 2013-01-23 11:50:27 <CodeShark> base58encoded using the proper version byte
 470 2013-01-23 11:50:35 <da2ce7> well I want to redeme it, so I don't add to block-chain bulk.
 471 2013-01-23 11:50:57 <CodeShark> redeeming it doesn't change the block chain bulk situation at all
 472 2013-01-23 11:51:11 <da2ce7> CodeShark: yes it dose,
 473 2013-01-23 11:51:18 <CodeShark> erm, no it does not
 474 2013-01-23 11:51:20 <da2ce7> un-redemed tx cannot be pruned.
 475 2013-01-23 11:51:28 <sipa> it changes the size of the unspent transaction output database
 476 2013-01-23 11:51:34 <sipa> but it doesn't change the size of the block chain
 477 2013-01-23 11:51:50 <CodeShark> yes, but does not affect the block chain size itself
 478 2013-01-23 11:51:58 <sipa> which is still something every fully validation node needs to process
 479 2013-01-23 11:52:17 <sipa> da2ce7: so if you're planning to use the block chain as a communication mechanism, please don't
 480 2013-01-23 11:52:45 <sipa> the only data that belongs there is whatever is necessary to validate transactions
 481 2013-01-23 11:52:59 <CodeShark> and advertisements :)
 482 2013-01-23 11:53:16 <da2ce7> sipa: I was thinking about using it for a 160 bit hash, for defining and revoking keys.
 483 2013-01-23 11:53:33 jdnavarro has quit (Ping timeout: 276 seconds)
 484 2013-01-23 11:54:27 <CodeShark> http://blockchain.info/address/11EtchABLockDotComEtchAXXXXYhe5Yp
 485 2013-01-23 11:58:51 <CodeShark> with good sized fees just to keep the miners happy
 486 2013-01-23 11:59:40 <da2ce7> hmm, over in OT land, we were thinking about having our master-key defined by a bitcoin address, For each output of a tx, it would define a sub-key.
 487 2013-01-23 12:00:21 <CodeShark> what's the point of this exercise?
 488 2013-01-23 12:00:25 <da2ce7> When a new tx is made, the any subkey not re-defined is considered revoked.
 489 2013-01-23 12:00:44 <da2ce7> well it gives us network enforced scripts.
 490 2013-01-23 12:00:54 <da2ce7> *well if we use a p2sh address.
 491 2013-01-23 12:01:10 tusle has left ()
 492 2013-01-23 12:03:48 <da2ce7> all the OT server needs to do is track what is the latest tx by a certan address (either standard, or p2sh, or whatever).
 493 2013-01-23 12:04:30 <CodeShark> it would be better to use some form of merged mining
 494 2013-01-23 12:05:10 <da2ce7> CodeShark: sure, but that is lots of effort; we want something that we can do now.
 495 2013-01-23 12:05:37 <da2ce7> it is not much different to coloured coins.
 496 2013-01-23 12:05:52 <sipa> coloured coins don't require any data in the block chain
 497 2013-01-23 12:06:42 theymos has joined
 498 2013-01-23 12:08:07 <da2ce7> there is a few ways of designing this; maybe we can just use the 160 hash of the sub-key's private key as the ID, then they will be just standard bitcoin addresses.
 499 2013-01-23 12:09:12 <da2ce7> I guess a tx with a message would work well as-well:  scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
 500 2013-01-23 12:09:27 yareyare has quit (Quit: mornings are evil)
 501 2013-01-23 12:09:41 <da2ce7> or even: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
 502 2013-01-23 12:09:55 <da2ce7> we don't care who spends the outputs.
 503 2013-01-23 12:10:37 <sipa> please don't use the block chain as a communication channel
 504 2013-01-23 12:10:47 <sipa> it is slow and incredibly expensive
 505 2013-01-23 12:11:27 <da2ce7> that is the point, we don't want to send much data, and we wan't network assured verification; we want something that is un-cencorable.
 506 2013-01-23 12:11:57 <sipa> seems to me you just need to have a transaction that commits to some data
 507 2013-01-23 12:12:10 <da2ce7> this means we can have a set of network-enforced rules tha goven the access to a nym.
 508 2013-01-23 12:12:24 rdponticelli has quit (Ping timeout: 276 seconds)
 509 2013-01-23 12:12:53 <sipa> there's a trick for that: use private key <real_private_key>*hash(data), with a corresponding address derived from <real_public_key>*hash(data)
 510 2013-01-23 12:15:57 <sipa> to anyone who knows the data, it is clear you had that data when creating the output
 511 2013-01-23 12:21:57 <HM> does multiplication not effect it then?
 512 2013-01-23 12:22:20 <HM> i guess it wouldn't as it's a modulus?
 513 2013-01-23 12:22:30 <sipa> it's EC multiplication
 514 2013-01-23 12:23:04 <sipa> for which the property: pubkey(private*number) = pubkey(private)*number holds
 515 2013-01-23 12:23:28 <HM> so here "data" can be some additional secret or password?
 516 2013-01-23 12:23:53 <HM> because you could use that with multisig
 517 2013-01-23 12:28:31 <da2ce7> ok, that should work fine.  if we use plain public key tx's outputs.
 518 2013-01-23 12:28:47 <da2ce7> <pubKey> OP_CHECKSIG
 519 2013-01-23 12:30:26 jdnavarro has joined
 520 2013-01-23 12:30:29 <sipa> a normal address works just as well
 521 2013-01-23 12:30:38 <sipa> if you reveal the real pubkey along with the data
 522 2013-01-23 12:32:29 valparaiso_ has joined
 523 2013-01-23 12:32:51 <da2ce7> <hash(hash(data))> OP_HASH160    be the smallest in the blockchain?
 524 2013-01-23 12:32:56 <Jouke_> anyone knows if znort987 is active on IRC?
 525 2013-01-23 12:35:07 valparaiso has quit (Ping timeout: 240 seconds)
 526 2013-01-23 12:35:09 valparaiso_ is now known as valparaiso
 527 2013-01-23 12:35:19 <sipa> da2ce7: yes, but that's not redeemable, unless data is a pubkey
 528 2013-01-23 12:40:44 <Luke-Jr> http://www.forbes.com/sites/jonmatonis/2013/01/22/bitcoin-casinos-release-2012-earnings/
 529 2013-01-23 12:41:00 <da2ce7> OP_HASH160 <hash160(hash(data))> OP_EQUAL;  where the subscript is hash(data)
 530 2013-01-23 12:42:20 <da2ce7> that would be fast to verify, as there is no EC cypto. :)
 531 2013-01-23 12:42:48 <sipa> also instantly stealable by any relaying node or miner
 532 2013-01-23 12:44:03 bitnumus_ has joined
 533 2013-01-23 12:47:40 <da2ce7> sounds just like what I want.  no chance of unspent tx clogging up the chain.  I'm not slowing down the verifcation much either.  The tx can be pruned out quite quickly.  Uses minimal space.
 534 2013-01-23 12:48:56 rdymac has joined
 535 2013-01-23 12:49:02 gjs278 has quit (Remote host closed the connection)
 536 2013-01-23 12:54:33 MrTiggr has joined
 537 2013-01-23 12:54:43 gjs278 has joined
 538 2013-01-23 12:54:46 Prattler has quit (Quit: ZNC - http://znc.in)
 539 2013-01-23 12:58:42 rdponticelli has joined
 540 2013-01-23 13:02:06 WolfAlex has joined
 541 2013-01-23 13:05:17 WolfAlex_ has quit (Ping timeout: 252 seconds)
 542 2013-01-23 13:07:00 JZavala has joined
 543 2013-01-23 13:07:04 agricocb has quit (Quit: Leaving.)
 544 2013-01-23 13:09:37 rdponticelli has quit (Ping timeout: 276 seconds)
 545 2013-01-23 13:12:58 <CodeShark> I still have a hard time understanding the appeal of playing a chance game where you have absolutely no chance for an edge and there's no skill involvd
 546 2013-01-23 13:13:58 <CodeShark> and the game doesn't even show bells and whistles nor cute art nor anything entertaining
 547 2013-01-23 13:14:48 <theymos> Yeah. Seems like the most boring way of gambling ever.
 548 2013-01-23 13:15:01 rdponticelli has joined
 549 2013-01-23 13:16:11 <CodeShark> I can understand the appeal of a game where you have to always pay but it involves skill - or a game of chance where you can obtain an edge
 550 2013-01-23 13:16:48 <CodeShark> but when you have neither, I just don't get it :p
 551 2013-01-23 13:18:22 <kuzetsa> http://en.wikipedia.org/wiki/Italian_lottery#Italian_lottery <--- so boring they made it illegal
 552 2013-01-23 13:19:08 b4epoche has quit (Read error: Operation timed out)
 553 2013-01-23 13:20:03 BTCOxygen has quit (Ping timeout: 255 seconds)
 554 2013-01-23 13:20:37 <kuzetsa> hi theymos :)
 555 2013-01-23 13:20:45 <theymos> Hi.
 556 2013-01-23 13:22:51 b4epoche has joined
 557 2013-01-23 13:26:24 daybyter has joined
 558 2013-01-23 13:33:51 theymos has quit (Remote host closed the connection)
 559 2013-01-23 13:36:30 rdponticelli has quit (Quit: No Ping reply in 180 seconds.)
 560 2013-01-23 13:38:51 rdponticelli has joined
 561 2013-01-23 13:42:14 ambimorph has joined
 562 2013-01-23 13:46:40 <HM> lotteries are about the chance of a big win
 563 2013-01-23 13:46:47 <HM> a form of escapism
 564 2013-01-23 13:48:30 <sipa> what frightens me is that people who seem to have a very good grasp on statistics sometimes also get into such games
 565 2013-01-23 13:49:07 JZavala has quit (Ping timeout: 240 seconds)
 566 2013-01-23 13:51:26 <HM> shoulda bought shares in satoshidice ;)
 567 2013-01-23 13:53:00 <HM> there's a boom in payment processing and exchanges
 568 2013-01-23 13:53:10 <HM> i don't find any of that innovative really
 569 2013-01-23 13:53:58 <HM> gambling is huge because it's banned in so much of the world
 570 2013-01-23 13:54:36 t7 has quit (Read error: Connection reset by peer)
 571 2013-01-23 13:55:03 t7 has joined
 572 2013-01-23 14:01:57 agricocb has joined
 573 2013-01-23 14:02:09 rdymac has quit (Remote host closed the connection)
 574 2013-01-23 14:07:25 rdymac has joined
 575 2013-01-23 14:07:28 rdponticelli has quit (Ping timeout: 276 seconds)
 576 2013-01-23 14:07:45 CodesInChaos has quit (Ping timeout: 264 seconds)
 577 2013-01-23 14:11:21 ciphermonk has quit (Ping timeout: 276 seconds)
 578 2013-01-23 14:13:57 rdponticelli has joined
 579 2013-01-23 14:23:05 <gavinandresen> sipa:  good news:  Bitcoin-Qt, leveldb17 branch, running overnight in XP has stable memory usage (140MB, peak usage ~200MB).
 580 2013-01-23 14:27:54 <MC-Eeepc> well im running it on xp too and can confirm
 581 2013-01-23 14:28:03 <MC-Eeepc> 140mb
 582 2013-01-23 14:28:43 <sipa> gavinandresen: but during IBD, it was significantly higher?
 583 2013-01-23 14:28:49 <gavinandresen> sipa: yes
 584 2013-01-23 14:29:37 <gavinandresen> sipa: 500MB memory usage during IBD isn't a show-stopper issue
 585 2013-01-23 14:30:27 <sipa> no, but it's much more than expected
 586 2013-01-23 14:32:00 rdymac has quit (Ping timeout: 248 seconds)
 587 2013-01-23 14:32:51 sacredchao has quit (Remote host closed the connection)
 588 2013-01-23 14:33:01 <MC-Eeepc> whats the defaut dbcache
 589 2013-01-23 14:33:41 <sipa> 25
 590 2013-01-23 14:33:52 BTCOxygen has joined
 591 2013-01-23 14:35:12 sacredchao has joined
 592 2013-01-23 14:36:54 <MC-Eeepc> seems low
 593 2013-01-23 14:37:33 <MC-Eeepc> more dbcache means it can do more chain checking in ram before stopping to dump it do disk right
 594 2013-01-23 14:37:37 rdymac has joined
 595 2013-01-23 14:40:35 <Seeraber> ANYbody selling any bitcoin site
 596 2013-01-23 14:40:48 <sipa> Seeraber: #bitcoin / #bitcoin-otc
 597 2013-01-23 14:40:49 <Seeraber> or know where to loook???
 598 2013-01-23 14:41:01 <Seeraber> thank
 599 2013-01-23 14:41:12 cdecker has joined
 600 2013-01-23 14:42:33 swappermall_ has joined
 601 2013-01-23 14:44:26 eckey has joined
 602 2013-01-23 14:44:46 <Luke-Jr> gavinandresen: do you plan to have sipa's HD wallet stuff in 0.8 btw?
 603 2013-01-23 14:45:23 <sipa> i think it's too late for that
 604 2013-01-23 14:45:24 BCBot has joined
 605 2013-01-23 14:46:06 <gavinandresen> way too late for wallet changes. Maybe a wallet re-implementation for 0.9
 606 2013-01-23 14:46:41 <kinlo> I'd like that, berkley still gives me the creeps
 607 2013-01-23 14:46:48 <Luke-Jr> hmm, didn't know it was late yet, ok
 608 2013-01-23 14:46:52 <Luke-Jr> maybe I should give master another try
 609 2013-01-23 14:47:11 <sipa> yes, i'd like to do all three wallet changes for 0.9 (drop vfWallet/ReacceptWalletTransactions, move away from bdb, BIP32)
 610 2013-01-23 14:48:03 <gavinandresen> … support for multi device wallets....
 611 2013-01-23 14:48:16 <kinlo> I'd hope to see the wallet to be seperated in 2 files, one containing only the keys and plaintext, one containing the transactions cache that could be rebuild at any time
 612 2013-01-23 14:48:23 <Luke-Jr> gavinandresen++
 613 2013-01-23 14:48:29 <gavinandresen> lets not design that now, though. I'd like to get a 0.8 release candidate out in the next few days
 614 2013-01-23 14:48:29 <sipa> kinlo: i'm completely against that :)
 615 2013-01-23 14:48:50 <Luke-Jr> kinlo: what about transaction metadata? ;)
 616 2013-01-23 14:48:55 <sipa> kinlo: transactions in a wallet are not a cache, and using it like that means you're using the blockchain as your wallet
 617 2013-01-23 14:49:09 <sipa> sure you won't lose confirmed money that way
 618 2013-01-23 14:49:36 safra has quit (Ping timeout: 248 seconds)
 619 2013-01-23 14:49:51 <TheSeven> can't hurt to be able to recover keys easily from a somehow broken wallet though
 620 2013-01-23 14:50:29 <sipa> that's something else :0
 621 2013-01-23 14:50:49 <iwoter> Luke-Jr--
 622 2013-01-23 14:50:57 <TheSeven> but then again, instead of basically exporting the keys into a key backup file, you could back up the wallet in the first place
 623 2013-01-23 14:51:07 <kinlo> Luke-Jr: put it in the plaintext one
 624 2013-01-23 14:51:13 <Luke-Jr> TheSeven: an append-only wallet file is pretty backup-friendly
 625 2013-01-23 14:51:37 <Luke-Jr> sipa: although rsync seems to play poorly with append-only files - it might make sense to split the file every so often
 626 2013-01-23 14:51:42 <TheSeven> and pretty unlikely to get corrupted in the first place
 627 2013-01-23 14:51:52 <sipa> kinlo: i just don't like the idea of depending on the ability to easily do a rescan of the blockchain
 628 2013-01-23 14:52:00 <iwoter> hey people, why cache transactions in a wallet file? aren't there indices around to the blockchain?
 629 2013-01-23 14:52:08 BCBot has quit (Remote host closed the connection)
 630 2013-01-23 14:52:14 <kinlo> Luke-Jr: why is that?  rsync should handle append only's just fine
 631 2013-01-23 14:52:24 <sipa> imho, historical blockchain data should only be necessary and used for bootstrapping a new full node
 632 2013-01-23 14:52:29 <Luke-Jr> kinlo: it seems to recheck the entire file :/
 633 2013-01-23 14:52:32 cdecker is now known as BCBot
 634 2013-01-23 14:52:42 <sipa> of course, you'd also use it in case of a lost wallet to recover things
 635 2013-01-23 14:52:51 <Luke-Jr> kinlo: debug.logs backup slowly as a result
 636 2013-01-23 14:53:02 <sipa> but considering the transactions in a wallet to be a cache means promoting the idea that block chain data is easily available
 637 2013-01-23 14:53:10 <Luke-Jr> iwoter: it's not a mere cache, it's information about your own transactions
 638 2013-01-23 14:53:12 <iwoter> sipa: everybody has the complete blockchain already, or am i wrong? has this been improved?
 639 2013-01-23 14:53:21 <Luke-Jr> iwoter: without that information, you don't know your balances etc
 640 2013-01-23 14:53:35 <sipa> iwoter: no electrum/multibit/ewallet user has the block chain
 641 2013-01-23 14:53:42 <kinlo> sipa: it shouldn't be needed, but in case a corruption occurs, it's better to be able to rebuild it based on other data
 642 2013-01-23 14:53:45 <TheSeven> iwoter: it is something that *should* be improved at least. so it makes no sense to build even more things on top of that bad assumption
 643 2013-01-23 14:53:48 <sipa> kinlo: of course
 644 2013-01-23 14:54:32 <kinlo> Luke-Jr: ofcourse, rsync doesn't *know* your data is append only, so it will need to read the entire file to make sure that not everything has changed... But that's something every backup tool will have to do....
 645 2013-01-23 14:54:36 <iwoter> Luke-Jr: well, isn't there an index that gives "all transactions involving address X" quickly?
 646 2013-01-23 14:54:42 <sipa> iwoter: there isn't
 647 2013-01-23 14:54:48 <sipa> iwoter: and there is no need for such a thing
 648 2013-01-23 14:54:53 <sipa> that's a nice thing
 649 2013-01-23 14:54:53 <Luke-Jr> iwoter: no
 650 2013-01-23 14:55:02 datagutt has joined
 651 2013-01-23 14:55:26 BCBot is now known as cdecker
 652 2013-01-23 14:55:30 <iwoter> not a bad thing to have. we could have desktop block-chain browsers
 653 2013-01-23 14:55:36 <sipa> let's not start depending on everyone keeping a fully indexed full history of all transactions ever around, shall we?
 654 2013-01-23 14:55:40 <iwoter> like blockchain.info, only a program
 655 2013-01-23 14:55:42 BCBot has joined
 656 2013-01-23 14:55:52 <sipa> iwoter: as an optional feature, i'm in favor of that
 657 2013-01-23 14:56:01 <sipa> iwoter: but not for wallets to depend on
 658 2013-01-23 14:56:07 <sipa> there is really no need for that
 659 2013-01-23 14:57:09 <sipa> in fact, i think wallets shouldn't depend on any local data present
 660 2013-01-23 14:57:52 <iwoter> depends on what you want a "wallet" to be
 661 2013-01-23 14:57:56 * TheSeven kinda likes the ideas behind armory
 662 2013-01-23 14:58:11 daybyter has quit (Quit: Konversation terminated!)
 663 2013-01-23 14:58:33 <iwoter> i always thought of it as just a collection of private keys, but i'm not into the code much. nice having a conversation here though!
 664 2013-01-23 14:59:07 <sipa> the only long-term viable client that is still a p2p node, is an SPV client (stores block headers + keys + transactions affecting wallet)
 665 2013-01-23 14:59:41 BCBot has quit (Client Quit)
 666 2013-01-23 14:59:47 <sipa> and any evolution that makes wallets depend more on local data present is a bad step for scalability of the infrastructure around bitcoin as a whole
 667 2013-01-23 15:01:46 rdymac has quit (Remote host closed the connection)
 668 2013-01-23 15:01:59 paraipan has joined
 669 2013-01-23 15:02:03 <iwoter> how about only having a peer-to-peer STATE
 670 2013-01-23 15:02:19 <iwoter> and only keeping the last part of the blockchain
 671 2013-01-23 15:02:35 <sipa> that's possible with the current code, actually
 672 2013-01-23 15:02:59 <iwoter> guess i haven't been updating myself well
 673 2013-01-23 15:03:08 <sipa> the only reason it's not implemented/enabled, is because it would make it very hard for nodes on the network to download history (which is still need for any fully validating node)
 674 2013-01-23 15:03:29 <sipa> but the database structure allows it
 675 2013-01-23 15:03:54 <sipa> so we first need some mechanism for nodes to distinguish between pruned and non-pruned (=archival) nodes
 676 2013-01-23 15:04:23 <lianj> sipa: the services field in version header?
 677 2013-01-23 15:04:28 cdecker has left ()
 678 2013-01-23 15:04:31 <sipa> lianj: yes, obviously
 679 2013-01-23 15:04:55 cdecker_ has joined
 680 2013-01-23 15:05:00 igetgames has quit (Read error: Connection timed out)
 681 2013-01-23 15:05:36 <iwoter> a client could mis-bootstrap from block 0
 682 2013-01-23 15:05:46 <iwoter> not sure i am understanding this right
 683 2013-01-23 15:06:05 <iwoter> so it could mis-bootstrap from the arbitrary point
 684 2013-01-23 15:06:32 <iwoter> choice between competing bootstrap points?
 685 2013-01-23 15:06:34 BCBot has joined
 686 2013-01-23 15:06:41 <iwoter> or states?
 687 2013-01-23 15:06:42 <sipa> wth is mis-bootstrapping?
 688 2013-01-23 15:06:53 <sipa> gavinandresen: not following re #2131... if you don't want malleability, it's certainly possible to introduce a v2 transaction with stronger restrictions, but you'll still need code to create even S signatures?
 689 2013-01-23 15:07:00 <iwoter> getting IP addresses that don't belong to the real bitcoin network
 690 2013-01-23 15:07:53 <iwoter> so if you have a protocol where a client asks for the state at a point, you could get a false state
 691 2013-01-23 15:07:55 <gavinandresen> sipa: I'm saying the problem isn't only even-or-odd signatures, the problem is that the signature can be changed.  I think we should allow either even or odd, and fix the "can be changed" part
 692 2013-01-23 15:08:08 <iwoter> sipa: is this the difficulty you were talking about?
 693 2013-01-23 15:09:10 <sipa> gavinandresen: well, preventing "can be changed" implies enforcing some constraint on the signature
 694 2013-01-23 15:09:56 <gavinandresen> sipa:  I'm saying put another signature on top of the txid.  So if you change the inner sig, the outer sig (only used during relaying) becomes invalid
 695 2013-01-23 15:10:08 <sipa> gavinandresen: how will you do that?
 696 2013-01-23 15:10:19 <gavinandresen> extra data in the 'tx' message
 697 2013-01-23 15:10:25 <sipa> eww
 698 2013-01-23 15:10:38 <gavinandresen> well, extra data tacked onto the end of the 'tx' message, if tx.version==2
 699 2013-01-23 15:11:05 <gavinandresen> why eww ?  It is a new transaction message....
 700 2013-01-23 15:11:26 <gavinandresen> old nodes will ignore the extra stuff, new nodes will parse it and enforce new rules
 701 2013-01-23 15:11:36 <sipa> seems like trying to solve the problem in the wrong place
 702 2013-01-23 15:11:52 <sipa> as you'll need to know a way to find the pubkey a transaction is coming from
 703 2013-01-23 15:11:57 <gavinandresen> not if "the problem" is "relaying nodes can change the txid"
 704 2013-01-23 15:12:09 <sipa> so the outer wrapping would still depend on the specifics of the script language
 705 2013-01-23 15:12:23 <gavinandresen> yes… To Be Determined...
 706 2013-01-23 15:12:52 <sipa> i'd rather have a v2 script language in that case, which changes the hashing system altogether
 707 2013-01-23 15:12:53 <gavinandresen> That's another "I don't' want to design it right now"
 708 2013-01-23 15:13:06 Luke-Jr has quit (Ping timeout: 245 seconds)
 709 2013-01-23 15:13:27 <iwoter> how about a hash of a state?
 710 2013-01-23 15:13:45 <sipa> iwoter: you mean the hash of the UTXO data?
 711 2013-01-23 15:14:18 <iwoter> i'm not very into the code, really, so i don't know UTXO. i'm just saying the "state"
 712 2013-01-23 15:14:28 <sipa> utxo = unspent transaction outputs
 713 2013-01-23 15:14:39 <iwoter> i guess that would be it
 714 2013-01-23 15:14:56 <iwoter> some normalized representation of it, hashed to give something that can be compared
 715 2013-01-23 15:14:56 <sipa> that together with the hash of the tip of the block chain defines the state you need to do full transaction validation
 716 2013-01-23 15:15:01 rdymac has joined
 717 2013-01-23 15:15:31 <iwoter> how about if one asked many nodes about a particular past state, to see if they agree
 718 2013-01-23 15:15:45 <iwoter> and only then downloads it
 719 2013-01-23 15:16:38 andytoshi has quit (Quit: WeeChat 0.3.9.2)
 720 2013-01-23 15:16:43 <sipa> that means you're exposing yourself to a sybil attack to enforce the most basic rules, like inflation
 721 2013-01-23 15:17:03 <iwoter> enforce what?
 722 2013-01-23 15:17:18 <sipa> sybil attack = all nodes you connect to are evil
 723 2013-01-23 15:17:28 <iwoter> well, that could happen with a bootstrap
 724 2013-01-23 15:17:30 <sipa> enforcing = verifying other nodes don't lie to you
 725 2013-01-23 15:17:43 <sipa> inflation = the rules governing how many coins a new block is allowed to introduce
 726 2013-01-23 15:18:25 <sipa> if you're going to trust other nodes to tell you the state, without its history, you're exposing yourself to the worst kind of lying
 727 2013-01-23 15:19:11 <sipa> so to have a fully validating nodes, which needs no trust in the network, you need to validate all history
 728 2013-01-23 15:19:17 <sipa> there is simply no way around that
 729 2013-01-23 15:19:25 <sipa> but that doesn't mean you need to keep all history around forever
 730 2013-01-23 15:19:37 <sipa> you can throw it away if you validated it
 731 2013-01-23 15:19:46 <iwoter> the whole bootstrapping business takes an annoying long time though
 732 2013-01-23 15:20:04 <iwoter> trying to get people to use bitcoin can be tough
 733 2013-01-23 15:20:11 <sipa> it takes around 7 minutes on laptop, when importing block data from disk, to get to block 210000
 734 2013-01-23 15:20:20 <sipa> *my
 735 2013-01-23 15:20:25 <sipa> with the latest code
 736 2013-01-23 15:20:35 <sipa> and a large cache
 737 2013-01-23 15:20:49 ciphermonk has joined
 738 2013-01-23 15:20:53 <sipa> and some optimizations that haven't been merged
 739 2013-01-23 15:20:59 <iwoter> i think it's like 6 GB now
 740 2013-01-23 15:21:07 <sipa> yes
 741 2013-01-23 15:21:18 <sipa> but downloading 6 GB isn't a problem these days, is it?
 742 2013-01-23 15:21:31 <iwoter> hmm, well, i don't know
 743 2013-01-23 15:21:55 <iwoter> depends where you are
 744 2013-01-23 15:22:16 <sipa> the slowness of the clients is not because it's hard; it's because a) the block fetching algorithm is stupid and b) the database code is very inefficient and causes extremely much I/O
 745 2013-01-23 15:22:23 <sipa> b) will be improved a ton in 0.8
 746 2013-01-23 15:22:39 <sipa> a) can be fixed for now by using bootstrap.dat
 747 2013-01-23 15:23:19 <gavinandresen> a UTXO hash at every checkpoint, compiled into the code, might be an OK idea.  But what problem are we trying solve?  Faster startup for newbies should be done by downloading headers first, then full blocks in the background IF (and only if) the newbie has a fast machine with lots of disk space.
 748 2013-01-23 15:24:55 <HM> if it's a GUI let the user decide
 749 2013-01-23 15:25:05 <HM> if it's a command line or server process then do the safest thing
 750 2013-01-23 15:25:07 <sipa> if we have headers-only mode, i think checkpoints should go away entirely :)
 751 2013-01-23 15:25:17 igetgames has joined
 752 2013-01-23 15:27:14 <sipa> you could have a "don't check signatures in history longer than X ago" - if you already have the headers in advance, you know you're on the best chain before validation of block data starts
 753 2013-01-23 15:28:07 rdymac has quit (Ping timeout: 240 seconds)
 754 2013-01-23 15:30:54 Luke-Jr has joined
 755 2013-01-23 15:35:33 rdymac has joined
 756 2013-01-23 15:41:02 <CodeShark> what if a signature claims a txout from many blocks ago?
 757 2013-01-23 15:41:26 luke-jr_ has joined
 758 2013-01-23 15:41:26 Luke-Jr has quit (Ping timeout: 245 seconds)
 759 2013-01-23 15:41:59 <sipa> CodeShark: what then?
 760 2013-01-23 15:42:19 <CodeShark> you need the tx to check the signature
 761 2013-01-23 15:42:42 <sipa> you only need the spending tx; not the tx being spent
 762 2013-01-23 15:42:48 <sipa> (only its txout is necessary)
 763 2013-01-23 15:42:52 <Jouke_> does the bitcoin client always use a new change address?
 764 2013-01-23 15:43:28 <sipa> CodeShark: and even that is irrelevant, as you'll have the tx at the time you're doing validation
 765 2013-01-23 15:43:39 <sipa> Jouke_: yes
 766 2013-01-23 15:43:52 <Jouke_> sipa: has it always done so?
 767 2013-01-23 15:44:01 <sipa> since very long ago
 768 2013-01-23 15:44:37 <Jouke_> 0.5.3?
 769 2013-01-23 15:44:43 <sipa> Jouke_: long before that
 770 2013-01-23 15:44:50 <Jouke_> Then I want to report a bug :P
 771 2013-01-23 15:45:01 <Jouke_> about 5.3 :P
 772 2013-01-23 15:45:05 <Jouke_> At least I think so
 773 2013-01-23 15:45:12 <sipa> if you can reproduce on 0.7.2, feel free
 774 2013-01-23 15:45:27 <Jouke_> tranasction: de9c987dbe2c6fd2d4fafbfdcbacabe04aa5af73ed3883d8305880f12102f2d1
 775 2013-01-23 15:45:36 ambimorph has quit (Ping timeout: 248 seconds)
 776 2013-01-23 15:46:06 <sipa> what about it?
 777 2013-01-23 15:46:39 <Jouke_> well, the 1EMnec address is used as an input aswell as the output
 778 2013-01-23 15:47:07 <Jouke_> that address is the one in my wallet
 779 2013-01-23 15:47:16 freakazoid has joined
 780 2013-01-23 15:47:25 <sipa> then i assume the other address is the change :)
 781 2013-01-23 15:47:49 <sipa> judging from the amount, that is even likelier
 782 2013-01-23 15:47:57 <CodeShark> I was about to say the same thing
 783 2013-01-23 15:48:03 <sipa> so you probably did a send-to-self
 784 2013-01-23 15:48:13 <Jouke_> Oh, hmmm
 785 2013-01-23 15:48:17 <CodeShark> highly unlikely that you send exactly .0101536 to someone and you get .01 change
 786 2013-01-23 15:48:27 <CodeShark> unless you intended it that way
 787 2013-01-23 15:48:44 <sipa> CodeShark: idea is: client starts up in headers-only mode (= SPV client), and in the background downloads history for the chain it considers best and validates it
 788 2013-01-23 15:49:06 <Jouke_> yes, you are right
 789 2013-01-23 15:49:10 <Jouke_> I did indeed
 790 2013-01-23 15:49:31 <sipa> CodeShark: so you do have all transactions available (this is independent from pruning, which could still be done after validationg), you just don't validate signatures for a part of the chain that you already know is buried deep
 791 2013-01-23 15:49:56 <CodeShark> sipa: I'm thinking that SPV clients' greatest vulnerability is for the most recent blocks
 792 2013-01-23 15:50:11 luke-jr_ has quit (Ping timeout: 245 seconds)
 793 2013-01-23 15:50:18 <sipa> sure
 794 2013-01-23 15:51:03 <CodeShark> so if you were to download entire blocks and just trust the current state (without validating signatures) and only validated the most recent several blocks, you'd probably be pretty safe
 795 2013-01-23 15:51:30 <sipa> which stage are you talking about?
 796 2013-01-23 15:51:44 <sipa> the SPV stage, or the upgrade-to-full stage?
 797 2013-01-23 15:51:55 <CodeShark> well, I'm thinking there's sort of an in-between stage
 798 2013-01-23 15:52:02 TD has joined
 799 2013-01-23 15:52:04 <CodeShark> SPV just deals with block headers
 800 2013-01-23 15:52:12 luke-jr_ has joined
 801 2013-01-23 15:52:16 CodesInChaos has joined
 802 2013-01-23 15:52:19 <CodeShark> full stage does full signature validation for the entire chain
 803 2013-01-23 15:53:00 <CodeShark> if you just download all blocks up until, say, the last ten and don't validate those blocks, you'd still be able to validate the last ten blocks
 804 2013-01-23 15:53:20 <TD> good day
 805 2013-01-23 15:53:35 <CodeShark> I guess you only need block headers and txouts
 806 2013-01-23 15:53:39 <sipa> CodeShark: you'd still need to build the UTXO set resulting from the N-10 first blocks, to be able to validate the last 10
 807 2013-01-23 15:53:45 <CodeShark> right
 808 2013-01-23 15:54:04 <sipa> and if you build the UTXO set, you're already almost validating everything except scripts
 809 2013-01-23 15:54:15 <CodeShark> but isn't the script validation the most expensive part?
 810 2013-01-23 15:54:27 <sipa> yes, but right now it's disabled before the last checkpoint
 811 2013-01-23 15:54:57 luke-jr_ is now known as Luke-Jr
 812 2013-01-23 15:55:05 <sipa> if we have headers-first mode, you could change the criterion "before the last checkpoint" to "long enough ago", as you've already validated the headers and know the PoW is valid
 813 2013-01-23 15:55:16 <sipa> so you can have the same speedup advantage without needing compiled-in data
 814 2013-01-23 15:55:28 <CodeShark> right, I was thinking rather than hardcoding checkpoints, you could just have an automatically sliding one
 815 2013-01-23 15:55:38 <sipa> that's basically what this means
 816 2013-01-23 15:55:53 <sipa> if you validate headers in advance, you don't need checkpoints to know you're on the right chain
 817 2013-01-23 15:56:20 <sipa> gavinandresen: which leveldb17 version did you test?
 818 2013-01-23 15:57:03 <gavinandresen> sipa: https://github.com/bitcoin/bitcoin/pull/2198
 819 2013-01-23 15:57:25 FredEE has joined
 820 2013-01-23 15:58:01 <sipa> gavinandresen: ok
 821 2013-01-23 15:58:08 <gavinandresen> … which I'll rebase right now....
 822 2013-01-23 15:58:50 <sipa> Luke-Jr: you're running my bitcoin-seeder, right?
 823 2013-01-23 15:59:15 <sipa> Luke-Jr: i have a script that combines the output of seeders to produce a seedlist in hex format like the net.cpp needs
 824 2013-01-23 15:59:39 <Luke-Jr> sipa: yes
 825 2013-01-23 16:02:04 asuk has joined
 826 2013-01-23 16:02:17 Cylta has joined
 827 2013-01-23 16:08:26 Prattler has joined
 828 2013-01-23 16:13:28 xyyyz has joined
 829 2013-01-23 16:15:55 rdymac has quit (Read error: Connection reset by peer)
 830 2013-01-23 16:20:11 Luke-Jr has quit (Ping timeout: 245 seconds)
 831 2013-01-23 16:22:52 Luke-Jr has joined
 832 2013-01-23 16:23:13 ambimorph has joined
 833 2013-01-23 16:24:02 ciphermonk has quit (Remote host closed the connection)
 834 2013-01-23 16:25:17 luke-jr_ has joined
 835 2013-01-23 16:25:18 ambimorph has left ()
 836 2013-01-23 16:25:21 ciphermonk has joined
 837 2013-01-23 16:25:52 rdymac has joined
 838 2013-01-23 16:26:33 <CodeShark> gavinandresen: I added a configure for bitcoin-qt
 839 2013-01-23 16:26:53 Luke-Jr has quit (Read error: Connection reset by peer)
 840 2013-01-23 16:27:08 DamascusVG has quit (Ping timeout: 252 seconds)
 841 2013-01-23 16:28:47 <luke-jr_> CodeShark: in case it's helpful, here is my GNUmakefile: http://codepad.org/bwVyLaJs
 842 2013-01-23 16:29:43 <gavinandresen> CodeShark: great. When you're done, squash all your commits. if it doesn't get pulled for the 0.8 release, it is likely to get pulled for 0.9
 843 2013-01-23 16:30:27 MrTiggr has quit (Ping timeout: 256 seconds)
 844 2013-01-23 16:30:43 <CodeShark> ok. I'd like to have it tested on a number of different distros and add any extra necessary details.
 845 2013-01-23 16:30:51 <MC-Eeepc>  configure?
 846 2013-01-23 16:32:32 <eckey> ;;bcauth eckey
 847 2013-01-23 16:32:32 <gribble> Request successful for user eckey, hostmask eckey!~chatzilla@gateway/tor-sasl/eckey. Your challenge string is: freenode:#bitcoin-otc:5d67fd141caaabcc4f3afe1687cd9a17ebad065d1b85fc0aa614d806
 848 2013-01-23 16:32:54 twixed has joined
 849 2013-01-23 16:33:30 <CodeShark> gavinandresen: we might also want to use the same flag names to set include and library paths for the different makefiles
 850 2013-01-23 16:33:38 <sipa> CodeShark: i'd really like to have your refactors that move stuff to core.h/cpp merged quickly after 0.8 final
 851 2013-01-23 16:35:05 <sipa> CodeShark: can you turn those in a commit that is strictly move only (so literally cut-pastes from main to core only) ?
 852 2013-01-23 16:35:21 <CodeShark> sipa: I can try
 853 2013-01-23 16:35:42 DamascusVG has joined
 854 2013-01-23 16:36:05 <sipa> so the first commit is just moves + an added #include "core.h" in main.h + core.o added to the makefiles
 855 2013-01-23 16:36:10 <CodeShark> sipa: it's a little more involved than that, though - since some of the methods of those classes had to be turned into regular functions
 856 2013-01-23 16:36:10 <luke-jr_> CodeShark: the existign makefiles already DO use the same config names..
 857 2013-01-23 16:37:00 <sipa> CodeShark: you can still those in a move-only way: leave it a method of the original class (which doesn't move), but move the implementation to core.cpp
 858 2013-01-23 16:37:21 <sipa> CodeShark: in a second commit you can then turn those into functions, with a definition in core.h
 859 2013-01-23 16:37:24 <CodeShark> luke-jr_: there are a few small subtleties - like, for instance, makefile.osx has no option to change the BDB_INCLUDE_PATH
 860 2013-01-23 16:38:00 <luke-jr_> CodeShark: doesn't OS X have some magic framework stuff?
 861 2013-01-23 16:38:08 rdymac has quit (Read error: Connection reset by peer)
 862 2013-01-23 16:38:24 ThomasV has joined
 863 2013-01-23 16:38:31 <CodeShark> luke-jr_:the include path for bdb is hardcoded into makefile.osx
 864 2013-01-23 16:38:38 ThomasV has quit (Client Quit)
 865 2013-01-23 16:38:50 <luke-jr_> ah
 866 2013-01-23 16:38:52 luke-jr_ is now known as Luke-Jr
 867 2013-01-23 16:39:26 <CodeShark> sipa: so then in a third commit we move those back to main?
 868 2013-01-23 16:39:35 <CodeShark> hmm
 869 2013-01-23 16:39:44 <CodeShark> the problem is that those functions have dependencies on structures in main
 870 2013-01-23 16:39:51 <sipa> CodeShark: oh, if it's things that remain in main, then they remain in main
 871 2013-01-23 16:40:00 <CodeShark> and the whole point of this exercise was to remove all core's dependencies from main
 872 2013-01-23 16:40:17 bitnumus_ has quit (Quit: Leaving)
 873 2013-01-23 16:40:17 <CodeShark> so if they remain in main, we have to pull them out of the class
 874 2013-01-23 16:40:25 <sipa> give an example
 875 2013-01-23 16:40:27 <CodeShark> which means a little more than just cut/paste
 876 2013-01-23 16:40:35 <CodeShark> ok, let me find one
 877 2013-01-23 16:41:00 bitnumus has quit (Quit: Bye)
 878 2013-01-23 16:41:05 <sipa> here's the idea: every function/method that needs to move from main to core, does so in the very first commit, without any other changes
 879 2013-01-23 16:41:31 <sipa> that means that this first commit doesn't help at all to break dependencies (you just get a #include "core.h"  in main)
 880 2013-01-23 16:41:55 <sipa> but it makes reviewing trivial, as the changes afterwards to do the actual dependency breaking becomes very small
 881 2013-01-23 16:42:27 <CodeShark> ok, sipa, example: bool CTransaction::CheckTransaction() const becomes CheckTransaction(const CTransaction& tx)
 882 2013-01-23 16:42:51 <CodeShark> https://github.com/bitcoin/bitcoin/pull/2154/files line 529/569 in main.cpp
 883 2013-01-23 16:43:10 <sipa> so, no change for that at all in the first commit, as this code doesn't move
 884 2013-01-23 16:43:39 <CodeShark> so just include main in core in the first commit?
 885 2013-01-23 16:43:46 <CodeShark> and keep that method inside the class?
 886 2013-01-23 16:43:49 <sipa> no, include main in core
 887 2013-01-23 16:43:52 <sipa> eh
 888 2013-01-23 16:44:02 <sipa> #include "core.h"  in  main.g
 889 2013-01-23 16:44:13 <sipa> (just realized the sentence was ambiguous)
 890 2013-01-23 16:44:14 <CodeShark> yes, that's what we want
 891 2013-01-23 16:44:19 <CodeShark> we do not want the other way around
 892 2013-01-23 16:44:34 <sipa> right, but i mean, the first commit doesn't do any dependency breaking
 893 2013-01-23 16:44:43 <sipa> so no changing #includes anywhere else
 894 2013-01-23 16:44:58 <sipa> it just does the code movement
 895 2013-01-23 16:45:18 <CodeShark> I'm still not sure if I'm understanding what you're saying, though - if we just move CTransaction from main to core, it will break these methods that depend on structures declared in main
 896 2013-01-23 16:46:44 <sipa> right
 897 2013-01-23 16:46:49 <sipa> i was confused
 898 2013-01-23 16:47:19 <sipa> so the first commit only changes stuff in .cpp files, i guess
 899 2013-01-23 16:47:30 <CodeShark> yeah, I think we need to do the commits in the reverse order
 900 2013-01-23 16:47:41 <CodeShark> first move the methods out from the class, then move the class to a new file
 901 2013-01-23 16:47:58 <sipa> you can move everything from main.cpp to core.cpp without breaking anything, but core.cpp will indeed do a #include "main.h" then
 902 2013-01-23 16:48:06 <CodeShark> right, that's the other alternative
 903 2013-01-23 16:48:23 <CodeShark> then move the stuff back to main, then remove the include
 904 2013-01-23 16:48:56 <CodeShark> I think I prefer the first way
 905 2013-01-23 16:49:22 <sipa> no no, you never move stuff back
 906 2013-01-23 16:49:41 <CodeShark> heh, I realize that "first way" is ambiguous
 907 2013-01-23 16:49:41 rdymac has joined
 908 2013-01-23 16:49:56 <sipa> you just move all CTransaction methods (except those that become functions in main) to core.cpp
 909 2013-01-23 16:49:57 <CodeShark> I mean, we first just edit main.cpp. then we pull stuff out to core
 910 2013-01-23 16:50:01 <sipa> in a first step
 911 2013-01-23 16:50:14 DamascusVG has quit (Ping timeout: 252 seconds)
 912 2013-01-23 16:50:17 <CodeShark> ?
 913 2013-01-23 16:50:27 <CodeShark> oh...
 914 2013-01-23 16:50:28 <sipa> that cannot break anything, right?
 915 2013-01-23 16:50:37 <CodeShark> well, I'm thinking now
 916 2013-01-23 16:50:38 lumberjak has quit (Read error: Connection reset by peer)
 917 2013-01-23 16:50:41 <CodeShark> there's the header files too
 918 2013-01-23 16:50:44 lumberjak has joined
 919 2013-01-23 16:51:23 <CodeShark> I have to check whether the class declarations depend on main
 920 2013-01-23 16:51:49 <CodeShark> yes, they do
 921 2013-01-23 16:52:28 FredEE has quit (Quit: FredEE)
 922 2013-01-23 16:52:37 <sipa> ... is there a problem moving the stuff in main.cpp that needs to be in core, to core.cpp in a first step?
 923 2013-01-23 16:52:50 rdymac has quit (Client Quit)
 924 2013-01-23 16:52:57 rdymac has joined
 925 2013-01-23 16:52:57 rdymac has quit (Client Quit)
 926 2013-01-23 16:52:59 <sipa> without any touching of those methods/functions, and without any changes to header files
 927 2013-01-23 16:53:11 <CodeShark> you mean without creating a core.h?
 928 2013-01-23 16:53:13 <sipa> yes
 929 2013-01-23 16:53:38 <CodeShark> no, I suppose if we leave the class declarations in main.h it won't break anything
 930 2013-01-23 16:54:23 Hashdog has joined
 931 2013-01-23 16:54:27 DamascusVG has joined
 932 2013-01-23 16:54:43 quinndupont has joined
 933 2013-01-23 16:54:44 <sipa> then in a second commit, turn methods in main.cpp into functions that remain in main.cpp
 934 2013-01-23 16:55:03 <sipa> then in a third commit, add core.h and include core.h in main.h, and move the classes to core.h
 935 2013-01-23 16:55:11 <CodeShark> that's doable, I suppose
 936 2013-01-23 16:55:14 <sipa> and in a fourth commit, break the dependencies
 937 2013-01-23 16:55:48 <sipa> so the first and third commit are move-only
 938 2013-01-23 16:56:37 <CodeShark> right, and the second is just pattern replacements, really
 939 2013-01-23 16:56:59 <sipa> exactly
 940 2013-01-23 16:57:29 <CodeShark> yeah, it makes sense to separate these two types of commits
 941 2013-01-23 16:57:38 <CodeShark> easier to check for correctnes
 942 2013-01-23 16:57:42 <CodeShark> *correctness
 943 2013-01-23 16:58:23 BTCOxygen has quit (Ping timeout: 246 seconds)
 944 2013-01-23 16:58:30 <CodeShark> well, the second might need to be broken up into two parts
 945 2013-01-23 16:58:36 <BlueMatt> in rpc methods table, safemd is...what?
 946 2013-01-23 16:58:37 Hashdog has quit (Ping timeout: 240 seconds)
 947 2013-01-23 16:59:30 <CodeShark> sipa: consider the AllowFree method in CTransaction
 948 2013-01-23 16:59:42 <CodeShark> it's implemented in main.h
 949 2013-01-23 16:59:51 <CodeShark> but it needs to be moved out of the class
 950 2013-01-23 17:00:08 <sipa> BlueMatt: allowed in safe mode
 951 2013-01-23 17:00:18 <CodeShark> which means it needs to be moved to main.cpp, then it needs to be turned into a regular function
 952 2013-01-23 17:00:18 <BlueMatt> ahh, thanks
 953 2013-01-23 17:00:37 DamascusVG has quit (Ping timeout: 245 seconds)
 954 2013-01-23 17:01:29 <CodeShark> actually, it needs to be gotten rid of altogether :)
 955 2013-01-23 17:01:37 <sipa> CodeShark: that's a separate issue
 956 2013-01-23 17:01:45 <CodeShark> no...it needs to be moved to main.h as a regular function
 957 2013-01-23 17:01:59 <sipa> CodeShark: so, do that in the second commit?
 958 2013-01-23 17:02:41 <CodeShark> I'm thinking it could be done in two commits - one that moves the implementation to outside the class declaration (still in main.h), the second that turns it into a regular function
 959 2013-01-23 17:02:54 toffoo has joined
 960 2013-01-23 17:02:57 freakazoid has quit (Ping timeout: 256 seconds)
 961 2013-01-23 17:02:58 <CodeShark> so we keep the moves and pattern replacement commits separate
 962 2013-01-23 17:04:03 <CodeShark> the move will not require any modifications in main.cpp
 963 2013-01-23 17:04:11 <CodeShark> but the pattern replacement will
 964 2013-01-23 17:06:15 <CodeShark> so four stages: 1) move core methods out of main.cpp and into core.cpp. 2) move implementations that should not be part of core classes out of their declarations and into either main.h or main.cpp. 3) turn these methods into regular functions and get rid of the method prototypes in the classes. 4) move the class declarations to core.h
 965 2013-01-23 17:06:28 da2ce7_d has joined
 966 2013-01-23 17:07:34 BTCOxygen has joined
 967 2013-01-23 17:07:51 DamascusVG has joined
 968 2013-01-23 17:07:52 t7 has quit (Quit: Leaving)
 969 2013-01-23 17:08:11 da2ce7 has quit (Ping timeout: 246 seconds)
 970 2013-01-23 17:08:23 jdnavarro has quit (Ping timeout: 252 seconds)
 971 2013-01-23 17:09:38 <xyyyz> The_Hidden_History_of_Money_and_Feudal_Order_Usury_Secrets.pdf	29.265 MB http://host01.fileconvoy.com/gf.php?id=g5871bb622c940e7e999205310.210243c2e012ac872e8d5b&sts=1358959823592447f484e4902dec5e12dd40be8c6b
 972 2013-01-23 17:09:56 porquilho has quit ()
 973 2013-01-23 17:10:06 <CodeShark> actually, for (2), into main.h only
 974 2013-01-23 17:10:14 <CodeShark> as an example, the AllowFree method
 975 2013-01-23 17:11:25 <CodeShark> so (1) only moves stuff out of main.cpp and into core.cpp. (2) only moves stuff within main.h. (3) only does pattern replacement in main.h and main.cpp. (4) only moves stuff from main.h to core.h.
 976 2013-01-23 17:11:35 eckey has left ()
 977 2013-01-23 17:12:11 <BlueMatt> Im gonna rebase #1549 (addnode rpc stuff) if anyone is interested in it for 0.8?
 978 2013-01-23 17:12:46 <Luke-Jr> BlueMatt++
 979 2013-01-23 17:14:15 bitafterbit has joined
 980 2013-01-23 17:15:11 <Jouke_> I have a bitcoinaddress, the corresponding private key, and all the transactions that are relevant to the address. Do I need to get the scriptPubKey to create a raw transaction?
 981 2013-01-23 17:15:20 Hashdog has joined
 982 2013-01-23 17:16:35 <CodeShark> Jouke_: for standard transactions, scriptPubKey is just OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
 983 2013-01-23 17:16:49 krysits has joined
 984 2013-01-23 17:16:55 <CodeShark> the pubKeyHash can be computed from the bitcoin address
 985 2013-01-23 17:17:49 <Jouke_> I am trying to use this simplified example: https://bitcointalk.org/index.php?topic=101525.0
 986 2013-01-23 17:17:49 <CodeShark> specifically, pubKeyHash is just the decoded value of the base58check encoding
 987 2013-01-23 17:18:05 <gavinandresen> BlueMatt: I like the add node stuff, if you can get a test plan written and executed by somebody other than yourself then I think it could sneak into 0.8
 988 2013-01-23 17:18:31 <Jouke_> CodeShark: does the createrawtransction do that for me?
 989 2013-01-23 17:18:41 FredEE has joined
 990 2013-01-23 17:18:42 <CodeShark> Jouke_: yes
 991 2013-01-23 17:19:10 <Jouke_> Ok, that makes life easier :0
 992 2013-01-23 17:19:11 <Jouke_> :)
 993 2013-01-23 17:19:39 <Jouke_> I was reading gmaxwell's signdemo and it confused me a bit.
 994 2013-01-23 17:19:51 <CodeShark> gavinandresen: what's the release timeframe for 0.8?
 995 2013-01-23 17:20:21 reizuki has quit (Read error: Operation timed out)
 996 2013-01-23 17:20:33 <gavinandresen> I'm thinking release candidate 1…. friday or saturday or sunday or monday.
 997 2013-01-23 17:21:13 <gavinandresen> then it depends on how testing goes.  If all goes well, no major bugs, then release candidate 1 could be the final 0.8.0 release in a couple weeks.
 998 2013-01-23 17:21:36 reizuki has joined
 999 2013-01-23 17:21:37 reizuki has quit (Changing host)
1000 2013-01-23 17:21:37 reizuki has joined
1001 2013-01-23 17:23:24 <BlueMatt> gavinandresen: you say that every time, but rc1 is NEVER final....
1002 2013-01-23 17:23:41 <gavinandresen> never say never....
1003 2013-01-23 17:23:46 <BlueMatt> well, ok
1004 2013-01-23 17:24:22 CodesInChaos has quit (Ping timeout: 245 seconds)
1005 2013-01-23 17:24:24 <gavinandresen> but yeah, I'd put the chances that rc1 is the last rc at… oh, 10%
1006 2013-01-23 17:24:37 <BlueMatt> seems generous, but...sure
1007 2013-01-23 17:25:09 <TD> hey there
1008 2013-01-23 17:25:15 <BlueMatt> hi TD
1009 2013-01-23 17:25:16 <gavinandresen> ho there
1010 2013-01-23 17:26:09 <gavinandresen> TD: where we at on full disclosure of the 0-confirmation issue?  are bitcoinj patches available to people who need them?
1011 2013-01-23 17:27:41 <TD> they're on a branch. i asked for a review a couple of days ago, i think the review will be wrapped up by EOD today or tomorrow CET
1012 2013-01-23 17:28:03 <gavinandresen> TD: good, that meshes with the 0.8rc release schedule
1013 2013-01-23 17:28:05 <TD> unless anyone spots any major issues i'll merge into master. unfortunately most wallet apps won't release them until i release a new stable bitcoinj
1014 2013-01-23 17:28:10 <TD> but i'm hoping that'll be RSN
1015 2013-01-23 17:28:29 <TD> my only remaining tasks are to merge bloom filtering, which is nearly there, and allow spending of unconfirmed change.
1016 2013-01-23 17:28:35 <TD> after that it's RC time.
1017 2013-01-23 17:28:41 <TD> gavinandresen: what about for the C++ side?
1018 2013-01-23 17:29:04 <CodeShark> sipa: I added a note to the pull request discussion so we don't forget :)
1019 2013-01-23 17:29:12 eckey has joined
1020 2013-01-23 17:29:13 <BlueMatt> TD: and I need to fix the new coinbase parsing bug
1021 2013-01-23 17:29:48 <eckey> FYI, I'm wondering if gribble fell over because I used quote marks in a PM...
1022 2013-01-23 17:31:21 <TD> BlueMatt: sure, though i don't want to hold 0.7 for full-verification bugs because there are a ton of improvements that will benefit SPV users.
1023 2013-01-23 17:31:27 <TD> but if it's a matter of a few days, ok
1024 2013-01-23 17:32:14 <BlueMatt> TD: yea, Im working on getting a test plan written for bitcoind #1549 now, then its on to bitcoinj...hopefully the bloom/full verif stuff can all be wrapped up in the coming day or two
1025 2013-01-23 17:32:59 <TD> superb
1026 2013-01-23 17:33:14 <BlueMatt> s/day/days/
1027 2013-01-23 17:33:20 <TD> sure
1028 2013-01-23 17:33:52 DamascusVG has quit (Ping timeout: 248 seconds)
1029 2013-01-23 17:34:14 <BlueMatt> s/days/day/ arg, I need to stop trying to correct grammar when I just read two words...
1030 2013-01-23 17:34:31 nus has quit (Ping timeout: 276 seconds)
1031 2013-01-23 17:34:51 b4epoche has quit (Ping timeout: 255 seconds)
1032 2013-01-23 17:35:50 eckey has left ()
1033 2013-01-23 17:37:21 <CodeShark> would it be possible to get pull request 2187 included in 0.8?
1034 2013-01-23 17:37:41 b4epoche has joined
1035 2013-01-23 17:39:00 nus has joined
1036 2013-01-23 17:39:14 DamascusVG has joined
1037 2013-01-23 17:39:15 DamascusVG has quit (Changing host)
1038 2013-01-23 17:39:15 DamascusVG has joined
1039 2013-01-23 17:39:58 DamascusVG has quit (Client Quit)
1040 2013-01-23 17:42:44 <BlueMatt> Luke-Jr: mind running the test plan I just posted on #1549?
1041 2013-01-23 17:43:31 <BlueMatt> shouldnt take more than a few minutes if you have a dns name with TTL of like 1 and modify the Sleeps in ThreadOpenAddedConnections to make them like 1 second
1042 2013-01-23 17:44:25 <CodeShark> sipa: thank you :)
1043 2013-01-23 17:47:37 FredEE has quit (Quit: FredEE)
1044 2013-01-23 17:48:59 quinndupont has quit (Ping timeout: 245 seconds)
1045 2013-01-23 17:51:23 t7 has joined
1046 2013-01-23 17:52:13 toffoo has quit (Ping timeout: 248 seconds)
1047 2013-01-23 17:58:56 kicek has quit (Ping timeout: 246 seconds)
1048 2013-01-23 18:02:09 tealcavalon has joined
1049 2013-01-23 18:03:35 <tealcavalon> hi there...
1050 2013-01-23 18:04:08 jdnavarro has joined
1051 2013-01-23 18:04:22 <tealcavalon> so is there anyone here that can tell me how the hell do I install a mining software in CENTOS 6?
1052 2013-01-23 18:04:42 TD has quit (Quit: TD)
1053 2013-01-23 18:11:43 kicek has joined
1054 2013-01-23 18:12:32 xyyyz has quit (Quit: Page closed)
1055 2013-01-23 18:13:01 terryww has quit (Ping timeout: 256 seconds)
1056 2013-01-23 18:13:18 LargoG has joined
1057 2013-01-23 18:13:46 freakazoid has joined
1058 2013-01-23 18:14:21 valparaiso has quit (Quit: valparaiso)
1059 2013-01-23 18:14:43 valparaiso has joined
1060 2013-01-23 18:20:37 <muhoo> hmm, this says keys are 25 bytes, but i've never seen an address less than 34 chars http://rosettacode.org/wiki/Bitcoin/address_validation
1061 2013-01-23 18:21:02 <gmaxwell> What says?
1062 2013-01-23 18:21:11 <muhoo> the ripemd looks like it's 20 bytes, which makes sense, plus the 4 byte checksum and the 1-byte header. but what's with those extra chars?
1063 2013-01-23 18:21:28 <muhoo> "a bitcoin address encodes 25 bytes"
1064 2013-01-23 18:21:34 <gmaxwell> muhoo: Thats correct.
1065 2013-01-23 18:21:42 <gmaxwell> _encodes_ 25 bytes into base 58.
1066 2013-01-23 18:21:57 <gmaxwell> which results in more characters since 58<256.
1067 2013-01-23 18:22:22 BTCOxygen has quit (Ping timeout: 244 seconds)
1068 2013-01-23 18:22:46 <muhoo> ok, then i need to stare at those code samples some more.
1069 2013-01-23 18:22:52 BTCOxygen has joined
1070 2013-01-23 18:24:08 <CodeShark> addresses can have fewer than 34 chars
1071 2013-01-23 18:24:39 <CodeShark> look at the base58check encoding of the all zero pubkeyhash
1072 2013-01-23 18:26:05 FredEE has joined
1073 2013-01-23 18:26:10 <CodeShark> https://bitcointools.appspot.com/?t=0000000000000000000000000000000000000000&f=hex
1074 2013-01-23 18:28:45 <CodeShark> the version 0 base58check (bitcoin address) is only 27 characters long
1075 2013-01-23 18:29:38 <CodeShark> technically speaking, a bitcoin address encodes 21 bytes since the last four are just a checksum
1076 2013-01-23 18:29:55 <CodeShark> and the first byte is just a version byte - so in the end it really represents a 20 byte number
1077 2013-01-23 18:30:01 <muhoo> and it seems to be encoding 0's as 1's too.
1078 2013-01-23 18:30:20 <CodeShark> yes, indeed - 1 in base58 represents 0
1079 2013-01-23 18:30:25 <muhoo> starting to make sense. i'm new to crypto so i apologize for the stupid questions.
1080 2013-01-23 18:30:44 <CodeShark> base58 encoding doesn't use the symbol 0 to avoid confusion with the letter O
1081 2013-01-23 18:31:38 <muhoo> aha, i see, it's an index in a table, "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
1082 2013-01-23 18:32:26 swappermall has joined
1083 2013-01-23 18:32:55 <CodeShark> http://blockchain.info/address/1111111111111111111114oLvT2
1084 2013-01-23 18:32:56 <CodeShark> :)
1085 2013-01-23 18:33:39 <muhoo> what? you just used it?
1086 2013-01-23 18:33:52 <muhoo> oh, someone did in november. bizarre.
1087 2013-01-23 18:34:20 <CodeShark> yes - several of us have created such transactions to play around with bitcoin data structures :)
1088 2013-01-23 18:34:42 <muhoo> like having a phonenumber of 555-555-5555
1089 2013-01-23 18:34:59 <upb> base58 is pretty strong crypto
1090 2013-01-23 18:35:02 <CodeShark> now finding a public key that hashes to all zeros is a serious challenge :)
1091 2013-01-23 18:35:23 <CodeShark> and finding a private key that has a public key that hashes to all zeros is even a greater challenge :)
1092 2013-01-23 18:35:27 <upb> in fact, the whole integrity of the bitcoin blockchain is based on the preimage resistiveness of base58
1093 2013-01-23 18:35:49 <CodeShark> actually, bitcoin's security has nothing to do with base58
1094 2013-01-23 18:36:01 <CodeShark> base58check is merely a convenience for human users to avoid typographical errors
1095 2013-01-23 18:36:12 <CodeShark> internally, bitcoin doesn't use base58check at all
1096 2013-01-23 18:36:32 <upb> you couldnt be more wrong
1097 2013-01-23 18:36:39 <CodeShark> I should say typographical/copy-paste errors
1098 2013-01-23 18:36:55 <CodeShark> the block chain's data structures have nothing to do with base58 encoding
1099 2013-01-23 18:37:09 maaku has joined
1100 2013-01-23 18:37:23 <muhoo> ripemd, looks like, under the hood
1101 2013-01-23 18:37:38 <upb> sure they do, the base58 stream cipher is an integral part of the bitcoin integrity puzzle
1102 2013-01-23 18:37:38 <CodeShark> yes, it's ripemd160 and sha256
1103 2013-01-23 18:37:48 <CodeShark> and internally it's all binary
1104 2013-01-23 18:37:53 <CodeShark> no base58
1105 2013-01-23 18:37:57 <gavinandresen> upb stop trolling please
1106 2013-01-23 18:38:59 <muhoo> don't worry, his attempted brain-cache-poisoning attack on me is failing.
1107 2013-01-23 18:40:23 ciphermonk has quit (Remote host closed the connection)
1108 2013-01-23 18:41:27 <sipa> CodeShark: actually, finding a pubkey that hashes to 160 zero bits is harder than finding a private key that matches a given pubkey :)
1109 2013-01-23 18:41:40 <CodeShark> yes, I was going to say, sipa :)
1110 2013-01-23 18:41:54 <CodeShark> true
1111 2013-01-23 18:42:46 <CodeShark> not even a quantum computer would help much
1112 2013-01-23 18:43:01 <upb> even with rainbow tables and DHT?
1113 2013-01-23 18:43:51 daybyter has joined
1114 2013-01-23 18:44:37 <sipa> updrainbow tables do not speed up anything
1115 2013-01-23 18:44:59 <sipa> they're just a compact way of storing a precomputed inversion table
1116 2013-01-23 18:45:02 <gavinandresen> he's still trolling….  I can tell by the "DHT"
1117 2013-01-23 18:45:12 <CodeShark> lol - totally incoherent technobabble
1118 2013-01-23 18:46:46 * gavinandresen thinks he'll have make a Quantum Rainbow DHT pull request on April 1....
1119 2013-01-23 18:46:51 <CodeShark> lol
1120 2013-01-23 18:47:19 BTCOxygen has joined
1121 2013-01-23 18:47:36 BTCOxygen has quit (Ping timeout: 256 seconds)
1122 2013-01-23 18:48:10 <sipa> gavinandresen: also announce we're switching to triple XOR for wallet encryption
1123 2013-01-23 18:48:58 <gavinandresen> "Eleventy-hundred times faster than AES!"
1124 2013-01-23 18:49:28 ThomasV has joined
1125 2013-01-23 18:49:44 terryww has joined
1126 2013-01-23 18:49:59 <sipa> which means OVER 9000 times faster
1127 2013-01-23 18:50:15 <sipa> oh, no
1128 2013-01-23 18:50:18 <sipa> math fail
1129 2013-01-23 18:50:23 <Luke-Jr> sipa: we can optimize triple XOR into a single XOR!
1130 2013-01-23 18:50:30 <upb> why not switch to RMX?
1131 2013-01-23 18:50:32 <upb> http://lesantint.com/leng/rmx_system.html
1132 2013-01-23 18:50:32 <kinlo> mmmz
1133 2013-01-23 18:50:41 <kinlo> guys use decent encryption please
1134 2013-01-23 18:50:49 <kinlo> triple hilights me :p
1135 2013-01-23 18:50:53 <upb> https://pbs.twimg.com/media/BBESuMICYAAvNn9.jpg:large
1136 2013-01-23 18:50:59 <kinlo> use aes or something, don't have a hilight on that :p
1137 2013-01-23 18:51:00 BTCOxygen is now known as 1!~kvirc@68.233.247.240|BTCOxygen
1138 2013-01-23 18:51:17 <Diablo-D3> gavinandresen, sipa: explain to me why aes256 is less secure than aes128
1139 2013-01-23 18:51:23 <Diablo-D3> gmaxwell too
1140 2013-01-23 18:51:25 <Luke-Jr> AFAIK, XOR isn't a bad idea in theory, but doing it right is probably less efficient than AES <.<
1141 2013-01-23 18:51:28 <BlueMatt> kinlo: like triple rot13?
1142 2013-01-23 18:51:45 <gmaxwell> Diablo-D3: You've mistaken us for Wikipedia, I fear.
1143 2013-01-23 18:51:49 <kinlo> BlueMatt: exactly :p
1144 2013-01-23 18:51:57 <Diablo-D3> wikipedia doesnt seem to cover it
1145 2013-01-23 18:52:08 <gmaxwell> It does, in fact.
1146 2013-01-23 18:52:19 <midnightmagic> Diablo-D3: There's an attack which works against aes-256 but not aes-128, which reduces the complexity of the attack on aes-256 to less than the complexity of a brute-force on aes-128
1147 2013-01-23 18:52:38 <Diablo-D3> midnightmagic: ... that sucks
1148 2013-01-23 18:52:46 <kinlo> Diablo-D3: it is on the wikipedia page
1149 2013-01-23 18:52:48 <gmaxwell> The attack is still to complex to actually worry about- its a certificational weakness.
1150 2013-01-23 18:52:59 <gmaxwell> s/to complex/too complex/
1151 2013-01-23 18:53:04 <Diablo-D3> kinlo: wasnt last time I checked
1152 2013-01-23 18:53:06 <kinlo> look for known attacks
1153 2013-01-23 18:53:06 denisx has joined
1154 2013-01-23 18:53:11 <kinlo> Diablo-D3: then check again...
1155 2013-01-23 18:53:17 <midnightmagic> Diablo-D3: It's still basically pointless to make the attempt; the attack is theoretical. It's still so hard that nobody would ever solve it. Point is the attack exists, and attacks often gain momentum. IMO.
1156 2013-01-23 18:53:29 <kinlo> look for Alex Biryukov
1157 2013-01-23 18:53:31 <sipa> upb: sounds really unbreakable indeed!
1158 2013-01-23 18:53:34 <Diablo-D3> so whats an alternative to AES?
1159 2013-01-23 18:53:46 <midnightmagic> Diablo-D3: IDEA?
1160 2013-01-23 18:53:48 grau has joined
1161 2013-01-23 18:53:49 <sipa> upb: thank god the chip cannot be reverse engineered
1162 2013-01-23 18:53:50 * midnightmagic ducks.
1163 2013-01-23 18:53:59 <gmaxwell> Diablo-D3: any of the AES finalists- though they aren't quite as well analyized as AES anymore.
1164 2013-01-23 18:53:59 <Diablo-D3> midnightmagic: ...
1165 2013-01-23 18:54:46 <kinlo> I'd stick to aes until the others have been properly investigated
1166 2013-01-23 18:55:03 <Diablo-D3> yeah, but using aes128 over aes256 doesnt seem like a valid solution
1167 2013-01-23 18:55:51 <gmaxwell> kinlo: at the time AES was selected they were equal to (or sometimes a bit more or less) AES in terms of analysis... but since then AES is much more interesting to attack for obvious reasons. There will be no 'until'.
1168 2013-01-23 18:59:47 <Diablo-D3> so what stops me from mashing together multiple AES finalists?
1169 2013-01-23 19:00:28 <gmaxwell> nothing... just don't use related keys
1170 2013-01-23 19:01:22 <Diablo-D3> what about key chaining, and the key output chooses the next algo
1171 2013-01-23 19:02:01 <gmaxwell> being excessively clever is often a good way to add weaknesses.
1172 2013-01-23 19:02:13 <Diablo-D3> well, that doesnt work anyhow
1173 2013-01-23 19:02:22 <Diablo-D3> if any of the algos are busted, it busts those blocks and all blocks that follow them
1174 2013-01-23 19:02:29 <gavinandresen> you're worried about the security of AES256???
1175 2013-01-23 19:02:38 <Diablo-D3> gavinandresen: vaguely
1176 2013-01-23 19:02:41 <gavinandresen> See: https://cryptolux.org/FAQ_on_the_attacks
1177 2013-01-23 19:02:47 <Diablo-D3> theoretical attacks often turn into real attacks
1178 2013-01-23 19:02:56 <CodeShark> there's a lot to be said for keeping the algos simple
1179 2013-01-23 19:02:57 <Diablo-D3> I dont panic like the slashdot crowd does though
1180 2013-01-23 19:03:13 <gavinandresen> "often" or "sometimes" ?   I'm not a cryptographer, I don't actually know….
1181 2013-01-23 19:03:25 <Diablo-D3> gavinandresen: as in "more than once"
1182 2013-01-23 19:03:34 <Diablo-D3> it only needs to happen once to ruin your day
1183 2013-01-23 19:04:04 <gavinandresen> sure, but you have to take into the possibility that it is likely to ruin somebody else's day first, giving you a chance to react....
1184 2013-01-23 19:04:10 <CodeShark> I don't think right now the greatest security weaknesses in our networks is in the crypto ciphers themselves
1185 2013-01-23 19:04:32 TD has joined
1186 2013-01-23 19:04:38 <Diablo-D3> CodeShark: yes, but key generation is largely a solved problem
1187 2013-01-23 19:05:04 <Diablo-D3> million round pbkdf2 sha512 is still pretty lethal to brute force
1188 2013-01-23 19:05:05 <gmaxwell> Diablo-D3: you meant something different from 'mashing together' than I thought you did.
1189 2013-01-23 19:05:06 <CodeShark> Diablo-D3: what do you
1190 2013-01-23 19:05:06 dust-otc has quit (Remote host closed the connection)
1191 2013-01-23 19:05:13 <CodeShark> mean by "solved problem"?
1192 2013-01-23 19:05:25 <Diablo-D3> gmaxwell: well, theres lots of ways of plugging them in
1193 2013-01-23 19:05:30 <Diablo-D3> CodeShark: I just said
1194 2013-01-23 19:05:31 <gmaxwell> Diablo-D3: I thought you means AES(k1,serpent(k2,data))
1195 2013-01-23 19:06:08 <gmaxwell> s/means/meant/
1196 2013-01-23 19:06:08 <Diablo-D3> gmaxwell: thats probably what I should have gone with
1197 2013-01-23 19:06:21 <Diablo-D3> gmaxwell: I went with excessively clever instead. oops.
1198 2013-01-23 19:06:44 <Diablo-D3> theres probably a way to wind them that works
1199 2013-01-23 19:07:35 <CodeShark> is it possible to mathematically prove that chaining with unrelated keys is no weaker than each cipher individually?
1200 2013-01-23 19:07:54 <Diablo-D3> CodeShark: yes
1201 2013-01-23 19:07:58 <Diablo-D3> you still need the other keys
1202 2013-01-23 19:08:35 <CodeShark> so weaknesses could still be introduced in the implementation, I suppose
1203 2013-01-23 19:08:49 <CodeShark> if you're not careful
1204 2013-01-23 19:08:53 <Diablo-D3> imagine a door with multiple locks, and you need all the keys
1205 2013-01-23 19:09:00 <Diablo-D3> opening a lock for free doesnt open the rest
1206 2013-01-23 19:09:08 <CodeShark> right, but weaknesses in the implementation can lead to timing attacks or other such things
1207 2013-01-23 19:09:21 <Diablo-D3> yes, but thats a larger general issue thats impl specific
1208 2013-01-23 19:09:27 <Diablo-D3> and thats not always a useful attack
1209 2013-01-23 19:09:31 <gmaxwell> CodeShark: it's easy to be no stronger than the worst though, at least under some attack models. (e.g. a meet in the middle if you have known plaintext)
1210 2013-01-23 19:09:31 <Diablo-D3> such as offline file storage
1211 2013-01-23 19:09:44 <muhoo> funny, he did force a long debate about encryption algorithms, looks like
1212 2013-01-23 19:10:03 <Diablo-D3> gmaxwell: yes, which is why I mentioned key generation being a solved problem
1213 2013-01-23 19:11:08 <CodeShark> my point is just that when you add complexity to your implementation it also gives you a chance to introduce implementation-specific weaknesses
1214 2013-01-23 19:11:19 <CodeShark> even if the cipher itself is theoretically sound
1215 2013-01-23 19:12:11 <Diablo-D3> CodeShark: yes/no
1216 2013-01-23 19:12:20 <Diablo-D3> what gmaxwell did adds no complexity
1217 2013-01-23 19:12:29 <CodeShark> you mean just simple chaining?
1218 2013-01-23 19:12:38 <CodeShark> yeah, I suppose so
1219 2013-01-23 19:12:55 <Diablo-D3> [01:48:15] <gmaxwell> Diablo-D3: I thought you means AES(k1,serpent(k2,data))
1220 2013-01-23 19:12:58 <gmaxwell> everything adds complexity.
1221 2013-01-23 19:13:43 <CodeShark> it adds a very small amount of complexity
1222 2013-01-23 19:13:52 porquilho has joined
1223 2013-01-23 19:15:20 Cylta has quit (Ping timeout: 252 seconds)
1224 2013-01-23 19:18:03 <wizkid057> Diablo-D3: should just use a DHT
1225 2013-01-23 19:18:13 <CodeShark> lol
1226 2013-01-23 19:25:58 paraipan has quit (Ping timeout: 276 seconds)
1227 2013-01-23 19:29:16 <Diablo-D3> okay so
1228 2013-01-23 19:29:17 <Diablo-D3> the AES attack
1229 2013-01-23 19:29:28 <sipa> gavinandresen: cool, how did you import those upstream leveldb changes into your branch?
1230 2013-01-23 19:29:41 <Diablo-D3> does this assume 256 bit keys?
1231 2013-01-23 19:29:55 <gavinandresen> git format-patch from a git clone of the leveldb repo, then a git am
1232 2013-01-23 19:30:25 <gavinandresen> git am --directory=src/leveldb  to be specific to remap the paths.  worked very nicely
1233 2013-01-23 19:30:51 paraipan has joined
1234 2013-01-23 19:31:04 runeks has quit (Quit: Leaving)
1235 2013-01-23 19:31:33 <gavinandresen> sipa: I'm compiling git HEAD on my 32-bit mac, I'll try a 2+gigabyte import and see what happens.  I believe it should Just Work.
1236 2013-01-23 19:34:14 tsche has quit ()
1237 2013-01-23 19:40:16 paraipan has quit (Remote host closed the connection)
1238 2013-01-23 19:41:41 reizuki has quit (Read error: Connection reset by peer)
1239 2013-01-23 19:41:46 <midnightmagic> Diablo-D3: You might want to look at the 100-year-cryptography project that zooko et al were looking at. They were talking about strong hashes and strong cryptography based on composable cryptographic algos..
1240 2013-01-23 19:42:07 reizuki has joined
1241 2013-01-23 19:42:07 reizuki has quit (Changing host)
1242 2013-01-23 19:42:07 reizuki has joined
1243 2013-01-23 19:42:12 paraipan has joined
1244 2013-01-23 19:42:36 D34TH has joined
1245 2013-01-23 19:42:36 D34TH has quit (Changing host)
1246 2013-01-23 19:42:36 D34TH has joined
1247 2013-01-23 19:45:49 mariusursache has quit (Quit: mariusursache)
1248 2013-01-23 19:50:22 rdymac has joined
1249 2013-01-23 19:54:00 <midnightmagic> speaking of key generation, does anybody know anything about intel's old 82802 fwh random number generator? has there been any new information about whether the old ones have been analyzed and maybe found lacking?
1250 2013-01-23 19:55:43 <CodeShark> are those the ones that use two oscillators, one modulated by a thermistor?
1251 2013-01-23 19:56:13 <CodeShark> I guess I could look it up but I'm too lazy :p
1252 2013-01-23 19:56:36 <midnightmagic> correct.
1253 2013-01-23 19:58:11 <midnightmagic> and then fed through a von neuman filter
1254 2013-01-23 19:58:25 <BlueMatt> TD: have you reproduced the coinbase parse fail in bitcoinj? I dont see how getSigOpCount could have thrown anything and I cant reproduce
1255 2013-01-23 19:59:06 <TD> i haven't tried
1256 2013-01-23 20:00:06 ThomasV has quit (Ping timeout: 255 seconds)
1257 2013-01-23 20:03:49 <midnightmagic> Could I make a suggestion? Could you guys (the devs) create a key bundle and communally sign it with your gpg keys?
1258 2013-01-23 20:03:49 <gavinandresen> anybody know off the top of their heads about which block number blk0001.dat rolled into blk0002.dat  ?
1259 2013-01-23 20:04:25 <midnightmagic> or maybe just all sign each others' keys?
1260 2013-01-23 20:04:28 <gmaxwell> gavinandresen: its wildly different for different people due to orphans, though I assume you mean in a compacted copy?
1261 2013-01-23 20:05:23 <gavinandresen> gmaxwell: sure, I just need an "at about block 111,000" estimate
1262 2013-01-23 20:08:01 <midnightmagic> For the individual PGP keys on bitcoin.org, you all don't appear to have signed each others' keys, so even though I'm fairly certain my copy of gmaxwell's key is accurate, he hasn't warranted that the rest of your keys are, so I can't triangulate naughtiness.
1263 2013-01-23 20:08:18 daybyter has quit (Read error: Connection reset by peer)
1264 2013-01-23 20:09:39 cetius has left ()
1265 2013-01-23 20:11:05 <gavinandresen> midnightmagic: https://github.com/bitcoin/bitcoin.org  has copies of our keys, and the nature of git means you can be pretty sure they haven't been tampered with
1266 2013-01-23 20:12:32 datagutt has quit (Quit: kthxbai)
1267 2013-01-23 20:12:37 jdnavarro has quit (Remote host closed the connection)
1268 2013-01-23 20:13:15 Diapolo has joined
1269 2013-01-23 20:13:32 <midnightmagic> gavinandresen: The gpg WoT is still helpful when using keyservers. Have you guys started fully signing commit pushes now?
1270 2013-01-23 20:14:53 <gavinandresen> midnightmagic: i have no idea what "fully signing commit pushes" means.  If it means digging out my private key on every push, that sounds like a bad idea.
1271 2013-01-23 20:17:16 <midnightmagic> gavinandresen: The Linux kernel devs do it to help audit the origin of code commits. Actual origin signed keys aren't necessary for this; a code-signing key can just be signed by your main key (or repudiated in the event you think it was compromised).
1272 2013-01-23 20:18:54 <gavinandresen> midnightmagic: okey dokey.  We're using github accounts instead; if we start getting lots of patches from non-github-account-people then I suppose that would make sense.
1273 2013-01-23 20:19:45 <gmaxwell> midnightmagic: I will not sign keys for people whos identity I haven't verified in person. Key hygiene in this community is terrible. We're also single threaded for security through github in any case. Persumably one sneaky addition to the repository can steal all our keys.
1274 2013-01-23 20:21:40 <midnightmagic> gmaxwell: What's the difference between seeing some random douche presenting you with a "midnight magic" key and you just verifying that the person you are communicating with has been 100% consistently able to prove he is the owner of the key he's using on-demand?
1275 2013-01-23 20:21:50 <midnightmagic> gmaxwell: Oh..  you verify the name too using ID?
1276 2013-01-23 20:22:19 <gmaxwell> midnightmagic: Yes.
1277 2013-01-23 20:22:39 <gmaxwell> And the email address by mailing back the signature instead of pushing it myself.
1278 2013-01-23 20:23:11 <Jouke_> With sendrawtransaction I got an error: {"code":-22,"message":"TX rejected"}. What does that mean?
1279 2013-01-23 20:23:36 <gmaxwell> Jouke_: see your debug.log, there is usually more information.
1280 2013-01-23 20:23:38 <midnightmagic> So..  would you sign my email-less key if you met me in person and I showed you ID?
1281 2013-01-23 20:23:45 <gmaxwell> Most common case is you didn't meet the fee rules for relay.
1282 2013-01-23 20:24:29 <midnightmagic> or rather.. *have* you ever signed anyone's key?
1283 2013-01-23 20:24:36 <gmaxwell> midnightmagic: Sure. I don't care to validate something that isn't there-  "nameless" is harder. What is the point of my signature if I validated _nothing_?  You might as well use a timestamping service to show a key is old.
1284 2013-01-23 20:24:55 <gmaxwell> midnightmagic: you could easily answer that question yourself. :P
1285 2013-01-23 20:25:06 <gmaxwell> (yes, dozens of them)
1286 2013-01-23 20:25:22 <gavinandresen> sendrawtransaction should be more specific in it's rejected reason, it'd be nice to know if it is rejected for fees or because it is non-standard or because signatures are invalid or some other reason
1287 2013-01-23 20:27:28 <Jouke_> gmaxwell: I can't see anything in debug.log
1288 2013-01-23 20:27:33 <midnightmagic> And here's an irritating WoT problem again, this time warranting trust.
1289 2013-01-23 20:28:16 <gmaxwell> Jouke_: tail the log and try again- you might just be missing it.  (though there may be reject reasons that don't get logged, I do know that fees get logged at least when debug is st)
1290 2013-01-23 20:28:21 <gmaxwell> s/st/set/
1291 2013-01-23 20:28:22 <midnightmagic> gmaxwell: How would you evaluate your trust of the other developers and their keys then?
1292 2013-01-23 20:28:33 <lianj> Jouke_: might pasting the tx?
1293 2013-01-23 20:28:37 <lianj> *mind
1294 2013-01-23 20:28:55 <midnightmagic> gmaxwell: Like, by the same notion, there's no real way for you to know gavin is gavin, and yet you work with him in a way that could significantly impact your finances.\
1295 2013-01-23 20:29:11 <midnightmagic> well "him" anyway.
1296 2013-01-23 20:29:45 <gavinandresen> code review is where most of our security comes from
1297 2013-01-23 20:29:55 <gavinandresen> … not blind trust that we won't screw up
1298 2013-01-23 20:29:59 <Jouke_> lianj: it is quite large
1299 2013-01-23 20:30:04 <gmaxwell> midnightmagic: I don't care that much if gavin is "gavin" but there is a convention in PGP keys, and no way to express that you didn't validate anything.
1300 2013-01-23 20:30:12 owowo has joined
1301 2013-01-23 20:30:32 <lianj> Jouke_: the hex of the tx is large? put in on some pastesite
1302 2013-01-23 20:30:41 <gmaxwell> and as gavinandresen says...  Trust really doesn't matter _that_ much, because mistakes are such an issue even when people are honest.
1303 2013-01-23 20:30:43 <midnightmagic> gavinandresen: I'm thinking of the untrustworthy github scenario where they feed everyone but you guys different data.
1304 2013-01-23 20:31:08 <gmaxwell> midnightmagic: if github is evil they stuff in a commit that adjusts the makefile to steal our gpg keys.
1305 2013-01-23 20:31:09 <midnightmagic> or.. more narrowly, feed me different data than anyone else, were I a paranoid git.
1306 2013-01-23 20:31:51 <midnightmagic> gmaxwell: Which ideally would trigger a repudiation of code-signing keys when you notice.
1307 2013-01-23 20:31:59 <gmaxwell> And unfortunately since we use the github merges, even if all the commits were signed that wouldn't really help you- since a github merge could insert malicious stuff for you.
1308 2013-01-23 20:32:10 <Jouke_> lianj: should I post the signed tx?
1309 2013-01-23 20:32:19 <gmaxwell> midnightmagic: if we even notice- of course once we've run the payload it could become invisible on our systems.
1310 2013-01-23 20:32:38 <lianj> Jouke_: if you dont manage to read the reason in the detail logs
1311 2013-01-23 20:32:45 <gmaxwell> I suppose it would be noticed eventually.. might be a while.
1312 2013-01-23 20:32:45 <lianj> s/detail/debug/
1313 2013-01-23 20:33:28 <midnightmagic> gmaxwell: The github merges are different than normal git merges?
1314 2013-01-23 20:33:52 <gmaxwell> midnightmagic: they're authored by github, so even if we're signing our commits they wouldn't be signed.
1315 2013-01-23 20:33:56 <Jouke_> Yeah I was overlooking it in the detail log
1316 2013-01-23 20:33:57 <gmaxwell> And the repository is full of them.
1317 2013-01-23 20:33:58 <Jouke_> ThreadRPCServer method=sendrawtransaction
1318 2013-01-23 20:33:59 <Jouke_> ERROR: ConnectInputs() : 6c19611eb2 prev tx already used at (nFile=1, nBlockPos=1191915617, nTxPos=1192033414)
1319 2013-01-23 20:34:08 <gmaxwell> Jouke_: there ya go.
1320 2013-01-23 20:34:45 <midnightmagic> O.O
1321 2013-01-23 20:35:21 <midnightmagic> I must be missing something. Can you tell me what's the purpose of that?
1322 2013-01-23 20:35:35 <Jouke_> So I did use an allready spent transaction.
1323 2013-01-23 20:35:37 * midnightmagic 's google-fu sometimes fails.
1324 2013-01-23 20:36:15 <gmaxwell> midnightmagic: purpose of what?
1325 2013-01-23 20:37:25 <midnightmagic> gmaxwell: I thought merges are submitted by humans and pushed. I guess I'm ignorant of why github is authoring commits.
1326 2013-01-23 20:38:49 <gmaxwell> people issue pull requests on the github site. There is a little merge button that does something analogous to git am -3  on the pull request (but with much more powerful conflict resolution than anything in the open source git software).
1327 2013-01-23 20:40:32 <midnightmagic> aaargh
1328 2013-01-23 20:42:04 xorgate has quit (Ping timeout: 256 seconds)
1329 2013-01-23 20:44:40 xorgate has joined
1330 2013-01-23 20:45:33 <midnightmagic> I guess the additional step of committing and signing the patch is an onerous pita.
1331 2013-01-23 20:45:44 <midnightmagic> f'in github. :(
1332 2013-01-23 20:46:51 rdymac has quit (Quit: This computer has gone to sleep)
1333 2013-01-23 20:47:03 <midnightmagic> well.. at least, the next time you guys meet in person, please consider doing some keysigning. :-)
1334 2013-01-23 20:47:28 rdymac has joined
1335 2013-01-23 20:49:04 tealcavalon has quit (Ping timeout: 248 seconds)
1336 2013-01-23 21:00:20 DaQatz has joined
1337 2013-01-23 21:02:22 Cory has quit ()
1338 2013-01-23 21:04:26 rlifchitz has quit (Ping timeout: 246 seconds)
1339 2013-01-23 21:05:34 sgornick has joined
1340 2013-01-23 21:05:58 rdymac has quit (Ping timeout: 264 seconds)
1341 2013-01-23 21:07:04 <muhoo> so what is the current best-practices way in bitcoinj to connect wallet to peergroup? is it PeerGroup.addWallet() ? or PeerGroup.addEventListener(Wallet.getPeerEventListener())?
1342 2013-01-23 21:07:11 <TD> addwallet
1343 2013-01-23 21:07:15 <TD> (on head)
1344 2013-01-23 21:07:18 <muhoo> thx
1345 2013-01-23 21:07:20 <TD> always use the most specific
1346 2013-01-23 21:08:10 <muhoo> in my testing so far, doing that doesn't actually make new transactions show up in the wallet, though they definitely show up in .isRelevantTransaction
1347 2013-01-23 21:09:07 <muhoo> wallet says "0 pending transactions" . but if i manually add it with commitTx, it works
1348 2013-01-23 21:11:59 rdymac has joined
1349 2013-01-23 21:13:23 <CodeShark> gavinandresen: I would also like pull request 2209 merged with master before 0.8 if possible
1350 2013-01-23 21:13:54 rdymac has quit (Read error: Connection reset by peer)
1351 2013-01-23 21:14:29 <muhoo> and PeerGroup.getPeerEventListener() clearly shows the wallet is there
1352 2013-01-23 21:14:44 <gavinandresen> CodeShark: not going to happen, will have to wait (too much risk, zero reward)
1353 2013-01-23 21:14:59 <CodeShark> it's very simple to confirm its correctness
1354 2013-01-23 21:15:22 tttt1 has left ()
1355 2013-01-23 21:15:58 <CodeShark> I'm trying to make these pull requests as minimal as possible so it's super simple to verify they don't break anything
1356 2013-01-23 21:16:06 <gavinandresen> you need to argue the 'zero reward' part if you want to budge me
1357 2013-01-23 21:16:24 <CodeShark> it will make merges much simpler later on :)
1358 2013-01-23 21:16:25 <gavinandresen> … and please don't bother
1359 2013-01-23 21:16:37 <gmaxwell> gavinandresen: Have I been rubbing off on you?
1360 2013-01-23 21:16:37 <CodeShark> we'll need to add this at some point
1361 2013-01-23 21:16:50 rlifchitz has joined
1362 2013-01-23 21:16:52 <CodeShark> one could argue that not having the locks is a bug
1363 2013-01-23 21:16:53 <gavinandresen> gmaxwell: yes, probably!
1364 2013-01-23 21:17:07 <CodeShark> even though the feature is not being used, something will break at some point if it isn't fixed
1365 2013-01-23 21:17:20 * gavinandresen puts his fingers in his ears and goes nanananananananana
1366 2013-01-23 21:17:24 <CodeShark> lol
1367 2013-01-23 21:17:34 <gmaxwell> CodeShark: 0.8 is kind of overfull overscarry already. I'd much rather work to make sure it can go in the next release than try to get it into 0.8. I can see lots of reasons to regret 0.8 and little to regret delaying it a little.
1368 2013-01-23 21:18:44 <CodeShark> I'm almost getting to the point now where rather than committing now and trying to merge later, I'm thinking how to write good patches that can survive any modifications to files like main.cpp
1369 2013-01-23 21:19:19 <muhoo> that's usually a good plan
1370 2013-01-23 21:19:32 Seeraber has quit (Read error: Connection reset by peer)
1371 2013-01-23 21:20:11 <muhoo> if you've hung around worlds like the linux kernel... jeebus, patches and patchsets are the currency there. you could make a full-time job out of just trying to make sure your patches survive what some other guy is doing in parallel to you
1372 2013-01-23 21:20:11 <CodeShark> most of the changes I'm looking at involve only cut/pastes or pattern replacements
1373 2013-01-23 21:20:15 <gmaxwell> CodeShark: fortunately were in fixing mode now- so I don't expect any major breakage for a bit.
1374 2013-01-23 21:20:55 rdymac has joined
1375 2013-01-23 21:21:06 <CodeShark> less central source files aren't as big an issue - but main.cpp is a huge one
1376 2013-01-23 21:21:26 <CodeShark> it's better to merge in the stuff that we know will need to go there at some point in the future and doesn't break anything sooner rather than later
1377 2013-01-23 21:21:30 <muhoo> i wouldn't fuck with something like main.cpp without taking a global lock :-)
1378 2013-01-23 21:21:56 <CodeShark> the qualifier, of course, is that it needs to be easy to assess its correctness and test it
1379 2013-01-23 21:22:24 <gavinandresen> yes, which is why right now is a bad time for do-nothing changes.
1380 2013-01-23 21:22:56 <CodeShark> ok...so if it doesn't make it into 0.8, could we try to merge it in right after 0.8?
1381 2013-01-23 21:24:05 <gavinandresen> no promises, but if the changes are easy to review and make the code obviously better then sure
1382 2013-01-23 21:24:25 <CodeShark> yes on both counts :)
1383 2013-01-23 21:24:31 <gavinandresen> but if there are 100 changes to review, then no matter how small that doesn't count as "easy to review"
1384 2013-01-23 21:25:47 Jamesonwa_ has joined
1385 2013-01-23 21:26:12 <Jamesonwa_> Looking to hire a bitcoin developer for a classified/bitcoin wallet based website
1386 2013-01-23 21:29:52 krysits has quit ()
1387 2013-01-23 21:33:07 <Diapolo> CodeShark: I guess it would be easier to review, to squash related commits and create smaller pulls of the big one. Easier to review and perhaps mergable without depending on the other pull?
1388 2013-01-23 21:35:29 <CodeShark> yes, Diapolo - that's the idea
1389 2013-01-23 21:36:23 <CodeShark> I have a couple branches with a bunch of modifications to a bunch of source files that, while not excessively complicated, are still not trivial to review and to test
1390 2013-01-23 21:36:39 <CodeShark> so I'd like to break it down into simple pulls
1391 2013-01-23 21:37:00 <CodeShark> I'd especially like to isolate commits that make modifications to files like main.cpp
1392 2013-01-23 21:37:34 <Diapolo> I would love it, if you do this because smaller pulls are things I often merge into my local build and check them out. The tooooo big ones I leave for more skilled devs ^^.
1393 2013-01-23 21:44:18 terryww has quit (Remote host closed the connection)
1394 2013-01-23 21:45:06 <TD> muhoo: ok, so the wallet thinks the transaction isn't relevant
1395 2013-01-23 21:45:12 <TD> muhoo: did you get it figured out?
1396 2013-01-23 21:48:47 porquilho has quit ()
1397 2013-01-23 21:50:04 b4epoche has quit (Ping timeout: 244 seconds)
1398 2013-01-23 21:50:09 asuk has quit (Quit: leaving)
1399 2013-01-23 21:51:12 knotwork_ has quit (Ping timeout: 256 seconds)
1400 2013-01-23 21:52:28 b4epoche has joined
1401 2013-01-23 21:53:17 knotwork_ has joined
1402 2013-01-23 21:55:47 <CodeShark> Diapolo: I've been tinkering a bit with bitcoin-qt...I'd like to develop a strategy for development on those branches so we won't be stepping on each other's toes
1403 2013-01-23 22:00:26 spaz926 has joined
1404 2013-01-23 22:01:34 <Diapolo> CodeShark: It's quite a lot about motivation so yeah, tell me your thougts ... I inted to be online for ~10 mins from now on ^^.
1405 2013-01-23 22:05:17 <CodeShark> so the main changes I've made revolve around supporting multiple wallets and dynamic loading/unloading
1406 2013-01-23 22:05:59 <CodeShark> so the main thrust is to have a control that can support multiple wallet views embedded into the BitcoinGUI window
1407 2013-01-23 22:06:43 <Diapolo> CodeShark: My problem with that pull is mostly that it is really hard to track those code-moves in there, which don't change base code.
1408 2013-01-23 22:07:00 <CodeShark> right, so I'm looking to clean up the commits
1409 2013-01-23 22:07:15 <CodeShark> I'm sort of a git noob - just getting the hang of it
1410 2013-01-23 22:07:17 spaz926 has quit (Quit: Bye!)
1411 2013-01-23 22:07:26 <Diapolo> Git is massive yeah
1412 2013-01-23 22:07:54 <CodeShark> when I first started out on the qt branch, I was at the same time studying the existing code and adding new functionality...so the commits are a little messy
1413 2013-01-23 22:08:31 <CodeShark> I'd move some stuff around, then I'd implement some new stuff, then I'd move stuff around again, etc...
1414 2013-01-23 22:08:45 <CodeShark> so I'd like to isolate the move-only commits from the implement new stuff commits
1415 2013-01-23 22:09:03 <Diapolo> CodeShark: pretty good idea and much easier to track
1416 2013-01-23 22:09:51 <CodeShark> I'd also like to stage the commits in such a way that the greatest dependency commits are staged earlier and in such a way as to avoid breaking things
1417 2013-01-23 22:10:23 <CodeShark> so simple reorganizations that then support the additional functionality but don't necessarily add new functionality in and of themselves should come first
1418 2013-01-23 22:10:48 <CodeShark> because these will be the hardest to merge later
1419 2013-01-23 22:11:08 <Diapolo> I really love to see someone working on the Qt side of things :). You rise another good point, where wumpus comes into play I think. Merge-prio (which leads to a rebase for smaller pulls perhaps and we need to get the best priority).
1420 2013-01-23 22:11:42 <wumpus> I think multi-wallet support is nice for 0.9
1421 2013-01-23 22:12:13 <CodeShark> the goal is to quickly arrive at a good common parent commit so we can each work on our own branch and merge only from that common parent
1422 2013-01-23 22:12:16 <wumpus> then again, the core stuff first needs to be merged, and that's up to gavin et al
1423 2013-01-23 22:12:49 <CodeShark> but we don't even need to add the multiple wallet backend yet to simply support the controls
1424 2013-01-23 22:13:13 <wumpus> yeah, that's true
1425 2013-01-23 22:14:52 <CodeShark> perhaps the biggest rearchitecture I did of bitcoin-qt was to move the wallet view stuff out of BitcoinGUI and into a separate class
1426 2013-01-23 22:15:08 <CodeShark> so overviewpage, sendcoinsdialog, etc...
1427 2013-01-23 22:15:20 <wumpus> yes which IMO was a good idea
1428 2013-01-23 22:15:35 <CodeShark> rather than making them part of centralWidget in the main window, I created a separate class called WalletView
1429 2013-01-23 22:16:01 <CodeShark> then on top of that, I created another class called WalletStack that manages multiple WalletViews
1430 2013-01-23 22:16:11 <CodeShark> so BitcoinGUI now makes the WalletStack object the centralWidget
1431 2013-01-23 22:16:19 <CodeShark> and just passes on messages to wallets to it
1432 2013-01-23 22:16:27 <CodeShark> and it then passes on those messages to the WalletViews
1433 2013-01-23 22:16:40 <wumpus> makes sense
1434 2013-01-23 22:17:36 <CodeShark> for a first merge commit, we don't have to incorporate any of the wallet loading/unloading code at all - we can just hardcode a single wallet in the init
1435 2013-01-23 22:18:00 <CodeShark> pwalletMain
1436 2013-01-23 22:18:06 <wumpus> right
1437 2013-01-23 22:19:06 <CodeShark> After doing the above, I added a list control so you could select a wallet...but that could be done in a later commit
1438 2013-01-23 22:19:30 <CodeShark> then I added the load/unload functionality
1439 2013-01-23 22:20:13 <CodeShark> anyhow, importantly, the BitcoinGUI class will be the biggest point of contention in merges if we don't have a good strategy
1440 2013-01-23 22:20:18 <wumpus> but indeed if you have a gui-only pull that doesn't depend on any core changes, that'd be much easier to merge
1441 2013-01-23 22:20:45 <CodeShark> changes to WalletView and WalletStack can be merged later without as much difficulty
1442 2013-01-23 22:20:57 <wumpus> it can be merged as soon as 0.8.0 becomes final
1443 2013-01-23 22:22:33 <CodeShark> I didn't think it merited to create a new widget class for the list control + the wallet stack...and could just make them both owned by BitcoinGUI and have BitcoinGUI connect all the signals and slots...but I'm starting to think that perhaps it would be a good idea to write a new Widget class
1444 2013-01-23 22:22:55 <CodeShark> since that means that we won't have to be editing BitcoinGUI.cpp and BitcoinGUI.h as much later on
1445 2013-01-23 22:23:26 <CodeShark> BitcoinGUI just sticks an instance of this widget as its central widget
1446 2013-01-23 22:23:33 <CodeShark> and passes on messages to it
1447 2013-01-23 22:23:43 <CodeShark> and we can leave BitcoinGUI alone
1448 2013-01-23 22:23:44 <wumpus> we should also be careful not to create too much (espeically small) classes and files, but if you can chop up bitcoingui.cpp into significant parts that'd be nice
1449 2013-01-23 22:24:31 <CodeShark> well, there are two competing interests here: on the one hand, we don't want to create a bunch of tiny classes and additional source files to keep track of...bot on the other hand, we want to make it so that classes like BitcoinGUI require the least amount of modification later on
1450 2013-01-23 22:25:18 <CodeShark> so basically I'm proposing one more class in addition to the two that I already mentioned
1451 2013-01-23 22:25:40 <CodeShark> for the first commit, we can just have it display a single walletstack instance
1452 2013-01-23 22:25:46 <CodeShark> and not incorporate the wallet list yet
1453 2013-01-23 22:25:48 <Diapolo> CodeShark: your view of things is much wider than mine, but nearly everything you said makes a lot of sense
1454 2013-01-23 22:26:07 copumpkin has quit (Ping timeout: 240 seconds)
1455 2013-01-23 22:26:15 <Diapolo> What I like is a good documentation of what your pull does, that helps me understanding your intentions :).
1456 2013-01-23 22:26:15 <CodeShark> Diapolo: thank you :)
1457 2013-01-23 22:26:20 Hashdog has quit (Remote host closed the connection)
1458 2013-01-23 22:26:30 <wumpus> yes it makes a lot of sense
1459 2013-01-23 22:26:42 copumpkin has joined
1460 2013-01-23 22:26:50 paraipan has quit (Remote host closed the connection)
1461 2013-01-23 22:27:02 knotwork_ has quit (Ping timeout: 276 seconds)
1462 2013-01-23 22:27:39 <Diapolo> I have really had zero experience with Qt or GUI stuff at all before getting interrested in bitcoin, you said you have a fair amount of experience so ... ^^
1463 2013-01-23 22:28:03 knotwork_ has joined
1464 2013-01-23 22:28:10 paraipan has joined
1465 2013-01-23 22:28:12 <CodeShark> I've only done a tiny bit with Qt in the past - but it's fairly simple to use and well-documented
1466 2013-01-23 22:28:33 <Diapolo> the documentation is great indeed
1467 2013-01-23 22:28:35 <CodeShark> it's a very nice library, actually
1468 2013-01-23 22:29:07 <Diapolo> cross-platform, which is what makes it perfect for us :) and digia seems to keep it updated, which is good
1469 2013-01-23 22:29:07 <CodeShark> I used to do MFC stuff on win32 back in the day - Qt is SOOO much nicer :)
1470 2013-01-23 22:30:37 <CodeShark> Qt even gets the subtle details of specific platform widgets right - like whether the OK button should be to the right or to the left of the Cancel button.
1471 2013-01-23 22:30:37 <Diapolo> I did that stuff via Borland C++ Builder, which we used at school ^^ I never ever directly touched MFC
1472 2013-01-23 22:30:48 <wumpus> be happy Diapolo ^^
1473 2013-01-23 22:31:02 * Diapolo is happe
1474 2013-01-23 22:31:04 <CodeShark> MFC required some hideous hacks to work
1475 2013-01-23 22:31:18 <CodeShark> a bunch of added macros to support message pumps
1476 2013-01-23 22:31:25 <Diapolo> wumpus: bzw. I reverted that hated deleteAction thing in the pull ^^
1477 2013-01-23 22:31:29 <wumpus> yes MFC was really hideous, probably made a whole generation hate on C++ and OOP :-)
1478 2013-01-23 22:32:11 <CodeShark> so I'll document the proposed changes - the three new classes and the proposed changes to BitcoinGUI
1479 2013-01-23 22:32:27 <CodeShark> if we can agree on this early on it will make things go much more smoothly moving forward
1480 2013-01-23 22:32:47 <wumpus> and MFC was from the VC6.0 times, also the worst c/++ compiler ever
1481 2013-01-23 22:33:28 <CodeShark> heh, yeah...and it sort of forced you to think in terms of an Office-like application
1482 2013-01-23 22:33:56 <CodeShark> multiple documents inside a main window, etc...
1483 2013-01-23 22:34:02 <Diapolo> CodeShark: agreed document what is intended and start implementing it with small pulls that don't rely on core stuff :)
1484 2013-01-23 22:35:47 <Diapolo> I hope you are okay with me commenting even "small" things I think are worth to get mentioned. I can be rather perfectionistic sometimes :D
1485 2013-01-23 22:35:54 <CodeShark> please do :)
1486 2013-01-23 22:36:00 <CodeShark> even stylistic things
1487 2013-01-23 22:36:12 <CodeShark> like the isEmpty() thing
1488 2013-01-23 22:36:28 <CodeShark> we're working in a few different stylistic frameworks: Qt, std, and boost
1489 2013-01-23 22:36:57 <CodeShark> boost tries to imitate std - but both of those are very different from Qt stylistically
1490 2013-01-23 22:37:14 <wumpus> yes, the gui is an isolated island from the rest of the code
1491 2013-01-23 22:37:16 <wumpus> that's on purpose
1492 2013-01-23 22:37:16 <Diapolo> I'm better at small things and support people that can create the bigger ones ^^.
1493 2013-01-23 22:37:49 <CodeShark> there will also be another point of contention with the multiwallet stuff - which is how to deal with supporting both RPC and an interactive GUI
1494 2013-01-23 22:38:08 <CodeShark> perhaps some RPC features will have to be disabled for the qt version
1495 2013-01-23 22:38:10 <wumpus> every communication with the core code goes through models, this is to make it easier to detach the two in separate processes communciating through a pipe later on
1496 2013-01-23 22:38:23 <CodeShark> yes, that's a good design
1497 2013-01-23 22:38:31 <gmaxwell> CodeShark: I thought the rpc was solved by just having a wrapper command?
1498 2013-01-23 22:38:47 <CodeShark> well, for instance, say a wallet is unloaded via RPC
1499 2013-01-23 22:38:53 <gmaxwell> I'd assume the gui could be solved via wraper tabs.
1500 2013-01-23 22:38:54 <CodeShark> what if the GUI had that wallet in focus
1501 2013-01-23 22:39:06 <gmaxwell> you can close an in-focus tab. :P
1502 2013-01-23 22:39:13 <wumpus> then close it
1503 2013-01-23 22:39:15 CodesInChaos has joined
1504 2013-01-23 22:39:16 <CodeShark> so the RPC should override the GUI?
1505 2013-01-23 22:39:16 <wumpus> use a notification
1506 2013-01-23 22:39:19 <wumpus> yes
1507 2013-01-23 22:39:22 <wumpus> the RPC is king
1508 2013-01-23 22:39:30 <Diapolo> guys that was / is a great talk, but my bed is calling very loud ... see ya
1509 2013-01-23 22:39:32 <wumpus> try sending quit while someone is using the UI :-)
1510 2013-01-23 22:39:44 <CodeShark> good night, Diapolo - to be continued
1511 2013-01-23 22:40:02 <wumpus> later Diapolo
1512 2013-01-23 22:40:47 <CodeShark> there are a few other differences between a GUI wallet and an RPC wallet - for instance, for the RPC wallet, it makes more sense to use startup options to determine what wallets to load at startup
1513 2013-01-23 22:40:58 <CodeShark> whereas with the GUI, it makes more sense to remember the state when you closed it
1514 2013-01-23 22:41:13 <wumpus> sure, that difference makes sense
1515 2013-01-23 22:41:18 <Diapolo> QSettings? and out :)
1516 2013-01-23 22:41:21 Diapolo has quit (Quit: Leaving.)
1517 2013-01-23 22:41:28 <wumpus> yes qsettings, the ui already has its own settings
1518 2013-01-23 22:41:56 <wumpus> which could include the currently loaded wallets
1519 2013-01-23 22:42:38 <wumpus> of course the ui should then be robust if though it should check then that the wallets are actually reachable, and not on some external harddrive that was detached
1520 2013-01-23 22:42:59 <CodeShark> right - if a wallet is not found, it might issue a warning but will recover gracefully
1521 2013-01-23 22:43:05 <CodeShark> and continue loading as many wallets as possible
1522 2013-01-23 22:43:33 <wumpus> it also adds an interesting mode: running without wallet?
1523 2013-01-23 22:43:47 <CodeShark> yeah - that makes a lot of sense for the headless version
1524 2013-01-23 22:44:03 <CodeShark> I have several bitcoind instances that I use strictly as verification/relay daemons
1525 2013-01-23 22:44:08 <CodeShark> and haven't even touched their wallets
1526 2013-01-23 22:44:29 <CodeShark> for the GUI version, without a wallet it doesn't make as much sense
1527 2013-01-23 22:44:46 <CodeShark> although there's no reason why we can't support loading no wallets
1528 2013-01-23 22:45:03 <CodeShark> other than backwards compatibility of the RPC
1529 2013-01-23 22:45:13 <wumpus> yeah it probably should be possible, though on the other hand having some 'default wallet' that cannot be unloaded may make sense for users...
1530 2013-01-23 22:46:09 <wumpus> otherwise they may screw themselves by unloading the wallet and thinking their coins are gone 
1531 2013-01-23 22:46:26 <CodeShark> yeah, perhaps we can have a "basic" and an "advanced" mode
1532 2013-01-23 22:46:35 <CodeShark> the basic mode just loads one default wallet
1533 2013-01-23 22:47:00 <CodeShark> or dunno - perhaps not worth the additional complexity
1534 2013-01-23 22:47:18 <gmaxwell> well, no wallet loaded is more potenitally buggy corner cases.
1535 2013-01-23 22:47:20 <CodeShark> perhaps just a good warning message if the user tries to close a wallet
1536 2013-01-23 22:47:43 <CodeShark> explaining what's happening - and with an option to not display it next time
1537 2013-01-23 22:48:05 <CodeShark> but we needn't worry about that too much just yet
1538 2013-01-23 22:48:24 <CodeShark> for the first integration, I envision still keeping a default wallet in a file called wallet.dat for backwards compatibility
1539 2013-01-23 22:48:31 <CodeShark> and denying the user the ability to unload it
1540 2013-01-23 22:48:42 ovidiusoft has quit (Quit: leaving)
1541 2013-01-23 22:48:43 CodeInChaos has joined
1542 2013-01-23 22:48:46 <CodeShark> more advanced users will probably not even use that wallet at all
1543 2013-01-23 22:48:46 CodesInChaos has quit (Ping timeout: 276 seconds)
1544 2013-01-23 22:49:13 <wumpus> exactly
1545 2013-01-23 22:49:18 <wumpus> they're always free to not use it
1546 2013-01-23 22:53:16 Cory has joined
1547 2013-01-23 22:55:52 ThomasV has joined
1548 2013-01-23 22:58:41 <CodeShark> it's interesting how it totally changes your coding strategy when you're able to reorder and reorganize commits :)
1549 2013-01-23 22:59:09 <CodeShark> I'm still getting used to having the ability to do that
1550 2013-01-23 23:01:39 pecket has quit (Read error: No route to host)
1551 2013-01-23 23:03:02 BTCOxygen has quit (Ping timeout: 252 seconds)
1552 2013-01-23 23:03:26 techlife has quit (Ping timeout: 252 seconds)
1553 2013-01-23 23:03:42 ovidiusoft has joined
1554 2013-01-23 23:06:15 MrTiggr has joined
1555 2013-01-23 23:07:24 techlife has joined
1556 2013-01-23 23:07:25 techlife has quit (Max SendQ exceeded)
1557 2013-01-23 23:07:30 pecket has joined
1558 2013-01-23 23:07:58 techlife has joined
1559 2013-01-23 23:07:59 techlife has quit (Max SendQ exceeded)
1560 2013-01-23 23:08:39 TD has quit (Quit: TD)
1561 2013-01-23 23:09:03 techlife has joined
1562 2013-01-23 23:09:04 techlife has quit (Max SendQ exceeded)
1563 2013-01-23 23:11:38 <sipa> CodeShark: would more advanced users that don't even use the wallet, use the Qt GUI?
1564 2013-01-23 23:12:17 <CodeShark> if it supported things like BIP32 and could detach from a headless daemon, sure :)
1565 2013-01-23 23:12:20 techlife has joined
1566 2013-01-23 23:12:21 techlife has quit (Max SendQ exceeded)
1567 2013-01-23 23:12:34 CodeInChaos has quit (Ping timeout: 264 seconds)
1568 2013-01-23 23:12:36 <sipa> wait... you said no wallet
1569 2013-01-23 23:12:43 <sipa> so how is BIP32 relevant?
1570 2013-01-23 23:12:52 <CodeShark> oh, you mean just using it as a verification/relay node?
1571 2013-01-23 23:12:54 techlife has joined
1572 2013-01-23 23:13:02 <CodeShark> the GUI doesn't really make too much sense for such usage
1573 2013-01-23 23:13:04 <sipa> well you guys are talking about a walletless mode, no?
1574 2013-01-23 23:13:19 <CodeShark> just saying that in principle you don't need to load a wallet to run bitcoind
1575 2013-01-23 23:13:25 <sipa> agree
1576 2013-01-23 23:13:56 <CodeShark> a GUI without a loaded wallet would be like a Word instance without an open document
1577 2013-01-23 23:14:27 <sipa> exactly
1578 2013-01-23 23:15:13 ovidiusoft has quit (Ping timeout: 245 seconds)
1579 2013-01-23 23:15:28 <CodeShark> I suppose the GUI could still provide realtime monitoring of the network and historical database query capabilities
1580 2013-01-23 23:16:42 <CodeShark> but I'm tempted to say these are separate apps
1581 2013-01-23 23:16:49 <CodeShark> perhaps they could all be integrated into a suite
1582 2013-01-23 23:17:01 BurtyBB has joined
1583 2013-01-23 23:17:19 <D34TH> --loadapp=nowallet.app
1584 2013-01-23 23:17:27 <D34TH> apps for everyone
1585 2013-01-23 23:17:29 <D34TH> :D
1586 2013-01-23 23:17:52 <gavinandresen> sipa: my 32-bit OSX laptop has been loading a 5+GB bootstrap.dat all day, it is up to block 187,000, should hit the 2GB mark soon
1587 2013-01-23 23:18:39 BurtyB2 has joined
1588 2013-01-23 23:18:50 bitnumus has joined
1589 2013-01-23 23:18:59 <sipa> gavinandresen: oh, if it even manages to open it, it's fine
1590 2013-01-23 23:19:29 <sipa> gavinandresen: as 0.8 doesn't do far seeks anymore
1591 2013-01-23 23:19:37 BurtyB has quit (Ping timeout: 240 seconds)
1592 2013-01-23 23:20:05 <sipa> on 32-bit linux it simply seems to ignore bootstrap.dat entirely
1593 2013-01-23 23:20:37 <sipa> gavinandresen: also, "all day"... how ancient is it?
1594 2013-01-23 23:21:00 ThomasV has quit (Ping timeout: 244 seconds)
1595 2013-01-23 23:22:17 BurtyBB has quit (Ping timeout: 245 seconds)
1596 2013-01-23 23:22:35 Hashdog has joined
1597 2013-01-23 23:25:40 grau has quit (Remote host closed the connection)
1598 2013-01-23 23:26:02 swappermall has quit (Read error: Connection reset by peer)
1599 2013-01-23 23:26:26 benkay has joined
1600 2013-01-23 23:28:18 RazielZ has quit (Ping timeout: 246 seconds)
1601 2013-01-23 23:28:34 bitafterbit has quit (Remote host closed the connection)
1602 2013-01-23 23:29:05 BTCOxygen has joined
1603 2013-01-23 23:30:56 yellowhat has quit (Ping timeout: 252 seconds)
1604 2013-01-23 23:31:32 agricocb has quit (Quit: Leaving.)
1605 2013-01-23 23:35:42 techlife has quit (Ping timeout: 252 seconds)
1606 2013-01-23 23:36:15 techlife has joined
1607 2013-01-23 23:36:18 twixed has quit (Quit: Leaving)
1608 2013-01-23 23:39:06 <benkay> hey y'all, what is a "chain code", as referred to in BIP_0032?
1609 2013-01-23 23:39:16 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1610 2013-01-23 23:39:26 <benkay> https://en.bitcoin.it/wiki/BIP_0032
1611 2013-01-23 23:39:50 dvide has joined
1612 2013-01-23 23:39:51 <sipa> it's just 256 bits of extra entropy
1613 2013-01-23 23:40:03 <gavinandresen> sipa: it's a 5-year-old Macbook Pro… so pretty ancient.
1614 2013-01-23 23:40:06 <sipa> so one can't just derive the subkeys using the parent key
1615 2013-01-23 23:40:20 <sipa> gavinandresen: still, all day sounds very bad
1616 2013-01-23 23:41:17 <gmaxwell> gavinandresen: do you have logs with timestamps?
1617 2013-01-23 23:41:40 <gmaxwell> it would be interesting to know if most of the time was before signature checking.
1618 2013-01-23 23:41:44 <benkay> thanks, sipa.
1619 2013-01-23 23:41:46 <gavinandresen> sipa: well, it's making steady progress, just slow.  no logs, I'm running -printtoconsole
1620 2013-01-23 23:42:06 swappermall has joined
1621 2013-01-23 23:42:20 <gavinandresen> sipa: memory usage looks ok, CPU usage is 10-20%, so my guess would be the hard drive is the bottleneck.
1622 2013-01-23 23:42:29 <sipa> what block are you at?
1623 2013-01-23 23:43:23 <gavinandresen> just passed 190,000
1624 2013-01-23 23:43:33 <sipa> 0.7.x or head?
1625 2013-01-23 23:43:43 * gmaxwell hopes
1626 2013-01-23 23:44:39 <gavinandresen> head
1627 2013-01-23 23:44:50 <gmaxwell> darn.
1628 2013-01-23 23:46:54 <sipa> gavinandresen: mind trying with a larger -dbcache (depending on how much ram you have) ?
1629 2013-01-23 23:47:05 <sipa> gavinandresen: -reindex should automatically continue from where it left off
1630 2013-01-23 23:47:14 <gavinandresen> sure; it's got 2GB ram
1631 2013-01-23 23:47:29 <sipa> a few hundred MB dbcache won't hurt then
1632 2013-01-23 23:47:43 <sipa> (don't specify -reindex again, i mean)
1633 2013-01-23 23:48:58 <gavinandresen> -dbcache=500 will get me 500MB cache?
1634 2013-01-23 23:49:12 <sipa> approximately, and up to
1635 2013-01-23 23:49:17 Climuff_ has joined
1636 2013-01-23 23:51:00 <gavinandresen> re-running with logtimestamps and -dbcache=500 ….
1637 2013-01-23 23:53:27 agricocb has joined
1638 2013-01-23 23:53:35 igetgames has left ("Leaving")
1639 2013-01-23 23:53:58 <benkay> how would one go about generating new public keys from a master public key, compatible with, say, electrum?
1640 2013-01-23 23:54:16 <benkay> i'm staring at bitcoin-address-utility in total confusion.
1641 2013-01-23 23:54:40 <sipa> benkay: no idea about any tool, but i heard electrum will implement bip32-style derivation when it becomes finalized
1642 2013-01-23 23:55:18 <gavinandresen> sipa: Verifying last 2500 blocks took almost 5 minutes….
1643 2013-01-23 23:55:50 <sipa> gavinandresen: CPU usage?
1644 2013-01-23 23:56:48 <benkay> neat! i assume that the client doesn't need the seed hashed with the public key to sign transactions that verify against the descendant public key?
1645 2013-01-23 23:57:24 <sipa> benkay: to sign transactions you need a private key, to verify them you need the corresponding public key
1646 2013-01-23 23:57:36 <sipa> benkay: bip32 or deterministic wallets in general don't change that
1647 2013-01-23 23:57:56 <sipa> it only changes how you obtain those private or public keys
1648 2013-01-23 23:58:05 <benkay> that's what I thought, thanks.