1 2013-01-10 00:05:26 toffoo has joined
   2 2013-01-10 00:11:14 <tcatm> zapsoda: divide by 1e8
   3 2013-01-10 00:17:43 St4renseN has quit ()
   4 2013-01-10 00:24:12 agricocb has joined
   5 2013-01-10 00:24:37 sgornick has joined
   6 2013-01-10 00:38:29 IniX has joined
   7 2013-01-10 00:39:12 rng29a has quit (Quit: Ex-Chat)
   8 2013-01-10 00:39:17 twixed has quit (Quit: Leaving)
   9 2013-01-10 00:46:38 <Luke-Jr> tcatm: is there a simple way to format it nicely? eg, a trailing zero for 0.10 BTC
  10 2013-01-10 01:03:23 deano has joined
  11 2013-01-10 01:04:24 <deano> Good evening.  Anybody have any thoughts on the invalid extra 0.01 bitcoins awarded on block height = 157785?
  12 2013-01-10 01:04:28 <deano> http://blockexplorer.com/block/0000000000000d34e30d0da09ff1da9252a17a432a32c3b745f196608ab51fad
  13 2013-01-10 01:05:54 <deano> (the last transaction seems to have an invalid coin input
  14 2013-01-10 01:07:16 rdymac has joined
  15 2013-01-10 01:09:21 <etotheipi_> deano, it's not invalid
  16 2013-01-10 01:09:33 <etotheipi_> it's certainly non-standard, but it's not invalid
  17 2013-01-10 01:10:05 <etotheipi_> the script to redeem that input is a binary string that hashes to "894eeb82f9a851f5d1cb1be3249f58bc8d259963832c5e7474a76f7a859ee95c"
  18 2013-01-10 01:10:15 <etotheipi_> and the OP_DROP before it is actually the answer
  19 2013-01-10 01:10:44 <etotheipi_> sha256(sha256('04678afd04678a')) is equal to that string
  20 2013-01-10 01:11:06 <etotheipi_> http://blockexplorer.com/tx/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e#o2
  21 2013-01-10 01:12:07 <etotheipi_> so, someone locked up 0.01 BTC in the blockchain with a transaction that doesn't need any signatures or anything to be redeemed... you only have to supply the correct string (and they even gave you the answer in the TxOut script)
  22 2013-01-10 01:12:58 <deano> okdoky.  I was wondering how a miner would have accepted it.
  23 2013-01-10 01:13:52 <deano> Strange :)  cool thanks for the insight etotheipi
  24 2013-01-10 01:13:54 <etotheipi_> if you see a funky script like that, you can click on the "Previous Output" and see the script
  25 2013-01-10 01:14:09 <etotheipi_> the way a miner evaluates it is:   txInScript prevTxOutScript
  26 2013-01-10 01:14:26 <etotheipi_> concatenates them together and then executes the result as a single script
  27 2013-01-10 01:15:15 trixisowned has joined
  28 2013-01-10 01:16:21 <deano> Does the latest version of bitcoin permit strange coin output scripts like this?
  29 2013-01-10 01:16:39 <etotheipi_> these scripts are pretty much DOA if you try to broadcast them
  30 2013-01-10 01:16:41 <deano> (I mean when considering transactions to relay and accept into blocks)
  31 2013-01-10 01:16:47 bitafterbit has quit (Remote host closed the connection)
  32 2013-01-10 01:16:48 <etotheipi_> no one will forward them or mine them
  33 2013-01-10 01:17:04 <etotheipi_> but if they show up in a block (like if you mine it yourself, or get someone else to), then all other nodes will accept them
  34 2013-01-10 01:17:32 <etotheipi_> (of course, only if they're valid)
  35 2013-01-10 01:17:50 <deano> Oh, haha, yea I guess it could get in that way, so long as the miner accepts such a script
  36 2013-01-10 01:18:13 Trix- has quit (Ping timeout: 256 seconds)
  37 2013-01-10 01:18:17 <etotheipi_> I'd say just about all the strange scripts on main-net are the miners themselves messing around
  38 2013-01-10 01:19:28 <deano> I was writing a bitcoin client, and so far I only included the standard 2 scripts... and I'm choking on that one... the first nonstandard script I've ran into beyond one that had a no-op in it
  39 2013-01-10 01:19:51 <etotheipi_> deano, it depends what you're trying to do with your application
  40 2013-01-10 01:19:59 <etotheipi_> in Armory, I just ignore non-standard scripts
  41 2013-01-10 01:20:01 <deano> I mean only included the ability to evaluate the standard 2 scripts
  42 2013-01-10 01:20:27 <etotheipi_> if you are using Armory, you're using standard scripts... if you have a non-standard script, then you created it manually and know how to redeem it manually
  43 2013-01-10 01:20:35 <sipa> etotheipi_: not sure if you were simplifying or not, but script evaluation is not just concatenate + run
  44 2013-01-10 01:21:17 <deano> My plan was to be able to validate every coin output amount in every transaction... so I kinda want to be able to verify every script
  45 2013-01-10 01:21:42 <etotheipi_> then listen to sipa :)  I don't do full script validation in Armory
  46 2013-01-10 01:21:43 <deano> I don't want to just "trust the network" that the coin amounts are correct
  47 2013-01-10 01:21:59 <etotheipi_> I leave it to my bitcoind/bitcoin-qt gateway to do that for me
  48 2013-01-10 01:23:40 <deano> sipa: what were you implying there is beyond concat & run?
  49 2013-01-10 01:24:16 <sipa> it used to be thatbway, in very early versions
  50 2013-01-10 01:24:42 <sipa> but then someone discovered they could just put OP_RETURN in the input scriot
  51 2013-01-10 01:24:58 <sipa> and have it return true for every output
  52 2013-01-10 01:25:13 <etotheipi_> oh, I didn't know about OP_RETURN
  53 2013-01-10 01:25:15 <sipa> so it was changed to two separate executions
  54 2013-01-10 01:25:33 <sipa> first the input script, then the output script
  55 2013-01-10 01:25:50 <sipa> the second execution inheriting the stack left bybthe first
  56 2013-01-10 01:26:29 <deano> ok, good, that is what I have in my code right now.
  57 2013-01-10 01:26:46 <etotheipi_> OP_RETURN seems like a pretty egregious operator
  58 2013-01-10 01:29:28 <deano> sipa, in my client that I've been working on, I only implimented a few of the script operations: DUP, EQUALVERIFY, CODESEPERATOR, CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY, the hashes, and NOP.  How many of the non-standard other operations have people used out of sillyness?
  59 2013-01-10 01:30:01 rdymac has quit (Quit: This computer has gone to sleep)
  60 2013-01-10 01:31:16 BurtyBB has joined
  61 2013-01-10 01:31:43 <etotheipi_> deano, I created a list of them on the old testnet
  62 2013-01-10 01:31:52 <etotheipi_> they used everything
  63 2013-01-10 01:32:24 <deano> nice.  punks.  etotheipi, where is this old testnet?
  64 2013-01-10 01:32:32 <etotheipi_> https://bitcointalk.org/index.php?topic=50523.0
  65 2013-01-10 01:32:48 BurtyB2 has joined
  66 2013-01-10 01:33:20 <etotheipi_> I guess it's not a real unit-test to run those scripts, but satoshi client deemed them all valid, so you should be able to run them
  67 2013-01-10 01:34:02 IniX has quit (Read error: Connection reset by peer)
  68 2013-01-10 01:34:05 BurtyB has quit (Ping timeout: 255 seconds)
  69 2013-01-10 01:34:43 <etotheipi_> also some good examples for doing multi-sig using addr160s instead of using public keys
  70 2013-01-10 01:35:04 <etotheipi_> (like 40 OP codes
  71 2013-01-10 01:36:15 B9Bot2 has quit (Ping timeout: 256 seconds)
  72 2013-01-10 01:36:47 BurtyBB has quit (Ping timeout: 264 seconds)
  73 2013-01-10 01:36:53 B6Bot2 has quit (Ping timeout: 255 seconds)
  74 2013-01-10 01:37:14 B0Bot2 has quit (Ping timeout: 255 seconds)
  75 2013-01-10 01:37:23 B7Bot2 has quit (Ping timeout: 256 seconds)
  76 2013-01-10 01:37:23 B3Bot2 has quit (Ping timeout: 264 seconds)
  77 2013-01-10 01:37:37 B5Bot2 has quit (Ping timeout: 252 seconds)
  78 2013-01-10 01:44:38 geb_ has quit (Excess Flood)
  79 2013-01-10 01:45:21 rdymac has joined
  80 2013-01-10 01:45:21 geb has joined
  81 2013-01-10 01:46:22 <deano> thanks for the help!  anybody else think the bond bubble will burst soon?
  82 2013-01-10 01:48:54 dvide has joined
  83 2013-01-10 01:49:18 dvide is now known as Guest31186
  84 2013-01-10 01:52:55 <zapsoda> http://pastebin.com/deGQgjdk
  85 2013-01-10 01:52:56 <zapsoda> Any ideas why that ^^^^ shows as "Unconfirmed Amount Received: 0.000000"  instead of 0.00000001?
  86 2013-01-10 01:54:07 BurtyBB has joined
  87 2013-01-10 01:55:33 <sipa> use %.8f
  88 2013-01-10 01:56:43 BurtyB has joined
  89 2013-01-10 01:56:45 BurtyB2 has quit (Ping timeout: 256 seconds)
  90 2013-01-10 02:00:05 maaku has joined
  91 2013-01-10 02:00:06 BurtyBB has quit (Ping timeout: 276 seconds)
  92 2013-01-10 02:01:27 Guest31186 has quit ()
  93 2013-01-10 02:04:52 asa1024 has joined
  94 2013-01-10 02:04:57 maaku has quit (Client Quit)
  95 2013-01-10 02:06:11 maaku has joined
  96 2013-01-10 02:06:15 <sipa> :t fixpoint (+1)
  97 2013-01-10 02:10:00 dvide has joined
  98 2013-01-10 02:10:08 maaku has quit (Ping timeout: 240 seconds)
  99 2013-01-10 02:16:52 maaku has joined
 100 2013-01-10 02:20:39 rdymac has quit (Quit: This computer has gone to sleep)
 101 2013-01-10 02:24:30 d4de has joined
 102 2013-01-10 02:26:49 nus has quit (Read error: Connection reset by peer)
 103 2013-01-10 02:27:06 nus has joined
 104 2013-01-10 02:27:38 freakazoid has quit (Ping timeout: 240 seconds)
 105 2013-01-10 02:29:33 JohnGalt2 has joined
 106 2013-01-10 02:30:45 JohnGalt has quit (Ping timeout: 260 seconds)
 107 2013-01-10 02:31:13 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
 108 2013-01-10 02:35:46 <etotheipi_> is there a good way to add "notification" to a JSON-RPC server?  Or does that need to be out-of-band?
 109 2013-01-10 02:37:01 <Luke-Jr> I have a pullreq for GBT longpolling, but that's only "good" for that one use case
 110 2013-01-10 02:37:23 EPiSKiNG- has joined
 111 2013-01-10 02:37:30 <etotheipi_> or rather, what mechanism would I use for notifying the user of new tx and new blocks, etc?  would it have to be through a separate connection through a different pid/port?
 112 2013-01-10 02:46:01 <Luke-Jr> etotheipi_: the existing strategy is executing a command, see -blocknotify
 113 2013-01-10 02:46:17 <Luke-Jr> etotheipi_: you can easily specify the command as curl to do HTTP requests
 114 2013-01-10 02:53:36 johzi has quit (Remote host closed the connection)
 115 2013-01-10 02:55:59 larsig has quit (Read error: Connection reset by peer)
 116 2013-01-10 02:59:20 owowo has quit (Quit: sayonara)
 117 2013-01-10 03:01:22 <gmaxwell> 17:00 < deano> Oh, haha, yea I guess it could get in that way, so long as the miner accepts such a script
 118 2013-01-10 03:01:43 <gmaxwell> ^ this sounded like deano thought that node accepted anything in blocks, but not so— it must actually be valid or the whole block is invalid.
 119 2013-01-10 03:05:20 <gmaxwell> So found out something somewhat sad tonight, was at dinner with someone responsible for a large isp and had a nice amusing conversation about customers (dos) attacking each other (apparently quit a few seemingly upstanding Korean corporations DOS the heck out of each other) and funny things done to address it (like simply putting them on the same switch and just happily billing them for the bandwidth).... and it was mentioned that they ...
 120 2013-01-10 03:05:26 <gmaxwell> ... had multiple customers request a whole bunch of small netblocks in distinctive /8s.
 121 2013-01-10 03:05:53 <gmaxwell> Apparently— companies in the business of poisoning bittorrent.  The bummer is, of course, once the infrastructure is built it's probably pretty cheap to get access to.
 122 2013-01-10 03:06:08 <gmaxwell> Oh well, one useful bit of resistance down the drain.
 123 2013-01-10 03:07:08 copumpkin has quit (Ping timeout: 260 seconds)
 124 2013-01-10 03:07:44 copumpkin has joined
 125 2013-01-10 03:16:33 copumpkin has quit (Ping timeout: 256 seconds)
 126 2013-01-10 03:17:08 copumpkin has joined
 127 2013-01-10 03:19:42 TheEslbear has joined
 128 2013-01-10 03:23:35 Eslbaer has quit (Ping timeout: 248 seconds)
 129 2013-01-10 03:28:18 <jgarzik> gmaxwell: poisoning how?  with peers that appear in trackers, yet misbehave?
 130 2013-01-10 03:33:12 <gmaxwell> I started to write a long speculative answer, then found this: http://en.wikipedia.org/wiki/Torrent_poisoning
 131 2013-01-10 03:35:42 <stealth222> isn't it too expensive to poison torrents to a degree that it would even make a dent?
 132 2013-01-10 03:35:47 <gmaxwell> getting a bunch of seperate /8s sounds like what you need to do to poison the DHT, see 'Eclipse Attack' on that page.
 133 2013-01-10 03:37:51 <gmaxwell> stealth222: who knows, what you can do and what you can sell aren't always the same thing. ... but also people on the defense side (in the anti-censorship, anti-drm, and anti-anti-piracy) seem to overestimate the attacker's goals. Making a torrent download only a bunch slower but still successful might sound like a lose but if your goal is to drive people to netflix it can be a big win.
 134 2013-01-10 03:45:46 <petertodd> gmaxwell: your time vulnerability, so what you're saying is you push the merchant's clock +70min, and the miner -70min, then a different miner +70min?
 135 2013-01-10 03:47:05 <petertodd> and the +70min miner creates a short fork for you to work with?
 136 2013-01-10 03:47:39 <petertodd> because unless you control the +70min miner, I would have though every block it got from the -70min miner it would build on, IE, it's not really a fork?
 137 2013-01-10 03:49:23 D34TH has quit (Quit: Leaving)
 138 2013-01-10 03:50:26 fiesh has quit (Ping timeout: 255 seconds)
 139 2013-01-10 03:52:49 <jgarzik> This is quite interesting: http://en.wikipedia.org/wiki/Torrent_poisoning#Selective_Content_Poisoning
 140 2013-01-10 03:54:48 fiesh has joined
 141 2013-01-10 03:56:45 some_name has joined
 142 2013-01-10 03:58:58 <petertodd> basically they're forking the dht network in a way that if you're not authorized to be on a fork, your performance will now suck in proportion to how many customers they have running their special software
 143 2013-01-10 03:59:05 <kjj> gmaxwell:  you still around?
 144 2013-01-10 03:59:20 <stealth222> doesn't it only take one person to remove any DRM measures and publish the content on a non-peer-authenticated network?
 145 2013-01-10 03:59:23 <petertodd> interesting how two companies distributing software under that scheme will make performance suck for each other's customer base
 146 2013-01-10 04:00:43 <stealth222> there's also that issue - if you have two or more different distributers sharing the same p2p network
 147 2013-01-10 04:00:49 <stealth222> *distributors
 148 2013-01-10 04:01:25 <petertodd> I suspect if the idea becomes popular one of the two different distributors would be happy to sue the other if they couldn't work something out...
 149 2013-01-10 04:06:16 _sgstair has joined
 150 2013-01-10 04:06:17 sgstair has quit (Disconnected by services)
 151 2013-01-10 04:06:18 _sgstair is now known as sgstair
 152 2013-01-10 04:08:01 <gmaxwell> petertodd: the -70 miner rejects the +70 miner, so the +70 goes fork, -70 is now rejecting and will build his own fork, it'll be shorter but accepted by the -70 merchant you are ripping off.
 153 2013-01-10 04:08:46 <stealth222> so the moral of the story is that merchants should make sure their clock is set correctly? :)
 154 2013-01-10 04:09:00 <gmaxwell> You move dunce bank and dunce pool -70 and move bozopool +70, eventually duncepool and dunce bank are on a fork, you deposit in dunce bank, withdraw different coins (that can get confirmed on the main network and conflict yourself on main.. then just walk away.
 155 2013-01-10 04:09:39 <gmaxwell> kjj: I'm around now.
 156 2013-01-10 04:09:58 <kjj> gmaxwell: is there a reason that the leveldb system can no longer find non-wallet, non-utxo transactions?
 157 2013-01-10 04:10:11 <gmaxwell> kjj: because we have no index of them.
 158 2013-01-10 04:10:30 <stealth222> the index should be optional at runtime
 159 2013-01-10 04:10:49 <gmaxwell> stealth222: please don't create confusion, at the _moment_ there is no such index.
 160 2013-01-10 04:11:10 <gmaxwell> with the coins database there is no need for a generic transaction index, maintaining one is costly. Having an optional one sounds useful, but code for that doesn't yet exist.
 161 2013-01-10 04:11:14 <stealth222> not trying to create confusion - trying to improve the program :)
 162 2013-01-10 04:11:15 <kjj> well...  I can see that in the future, a node that is actually pruning simply won't be able to provide that information unless it is willing to relay a request to a non-pruned node
 163 2013-01-10 04:11:46 <petertodd> ah I see, it's the bank whose clock was pushed back, and a large mining pool is who gets pushed forwards, and by being pushed forwards they'll cause (if large enough) the rest of the network to build blocks with such far timestamps
 164 2013-01-10 04:11:51 <gmaxwell> Having a _local_ index sounds interesting, having a network facing one is a feature I'd NAK without some serious effort to convince me.
 165 2013-01-10 04:12:16 <petertodd> gmaxwell: so then why can't you just limit the adjustment to <60 minutes? what if it were limited to 30 minutes?
 166 2013-01-10 04:12:19 <gmaxwell> petertodd: No, they don't force the network to. (well if you pushed LOTS forward)
 167 2013-01-10 04:13:02 <gmaxwell> petertodd: errors of 60 minutes are not uncommon due to daylight saving stupidity. So limiting it to 60 would make it fail for someone with a few minutes skew plus dst, which would be sad.
 168 2013-01-10 04:13:09 <kjj> I take it the code for the current bdb txid index is sufficiently non-trivial to port to leveldb, right?
 169 2013-01-10 04:13:25 <petertodd> yeah, I'm assuming say deepbit + slush, enough that the average starts to climb
 170 2013-01-10 04:14:01 <petertodd> gmaxwell: so basically what I said before about how the window should have been more like 4 or 5 hours would prevent this attack? gah
 171 2013-01-10 04:14:27 <gmaxwell> petertodd: Sure, but it's not needed say I push bozopool forward, he mines a block X 70 minutes into the future now dunce bank rejects block X and and blocks on the longest chain after X.
 172 2013-01-10 04:15:16 denisx has quit (Quit: denisx)
 173 2013-01-10 04:15:46 <petertodd> ah of course, the one invalid block makes the rest of the chain look invalid to dunce bank
 174 2013-01-10 04:16:31 <gmaxwell> if the forward window (blocks from the future we'd accept) went 4-5 hours then this wouldn't be an issue but there would be more incentive for miners to lie to push down the difficulty.   Another alternative is if the skew is too big (e.g. >±35 minutes) refuse to mine and show all transactions as unconfirmed. So it just reduces to a DOS attack.
 175 2013-01-10 04:16:58 <gmaxwell> That combined with forgetting and potentially treating inbound differently than outbound would probably close it as an attack pretty completely.
 176 2013-01-10 04:17:12 johzi has joined
 177 2013-01-10 04:18:33 <petertodd> yes, but the lie to push down the difficulty is a one time thing for consistantly mining miners, they can push the time +4hours, but once that's been done you can't push it an additional +4 hours
 178 2013-01-10 04:19:05 <gmaxwell> E.g. do seperate medians of outbound and inbound, and if they disagree do {something} (refuse to mine/show all txn as unconfirmed, ignore inbound) I dunno. There is a lot of maybe you can sling at this issue. I've known about this potential behavior for almost two years and haven't considered it important enough to think much about.
 179 2013-01-10 04:19:11 <petertodd> 4hours/2weeks is just 1%
 180 2013-01-10 04:19:39 <gmaxwell> petertodd: in any case, thats off the table because its a (soft)forking blockchain rules change.
 181 2013-01-10 04:19:40 <petertodd> the best advice for duncebank is probably just use ntp
 182 2013-01-10 04:20:23 <petertodd> absolutely off the table, although a 95% buy-in transition could work if it turns out to be a problem
 183 2013-01-10 04:20:26 <petertodd> as you say
 184 2013-01-10 04:20:27 <stealth222> I agree - if your clock is not set correctly it's really your damn fault :)
 185 2013-01-10 04:20:34 <kjj> everyone should always be using NTP, since like 1998
 186 2013-01-10 04:20:43 <gmaxwell> petertodd: meh, depending on NTP is risky too, its is a _very_ poorly secured centerally controled infrastructure which has been amusingly wrong randomly on accident even in recent memory (Extra leap seconds for everyone!). But having some safe-mode triggered by ntp and bitcoin time disagreeing would be smart.
 187 2013-01-10 04:21:00 <stealth222> then use GPS :P
 188 2013-01-10 04:21:25 <stealth222> GPS perforce must be accurate
 189 2013-01-10 04:21:27 rdponticelli has quit (Ping timeout: 276 seconds)
 190 2013-01-10 04:21:54 <gmaxwell> Which is a centerally controlled infrastructure with geographic targeting for attacks, altough if the US military is your enemy you have bigger problems (drones!)
 191 2013-01-10 04:22:05 <kjj> well, GPS accuracy isn't a sure thing.  there are even mechanisms for making it intentionally inaccurate
 192 2013-01-10 04:22:16 <petertodd> kjj: everyone should spend the extra $5 on an accurate clock... temperature compensated RTC's are easy to get these days, +-3.5ppm costs $5 (maxim's ds3232 for example)
 193 2013-01-10 04:22:34 <gmaxwell> stealth222: not only must it not be accurate but in fact the ability to geographically target inaccuracy is built in, and civilian gps is easialy terrestrially  jammed or faked out.
 194 2013-01-10 04:22:53 <petertodd> for critical stuff like this it's better to only use ntp to set the clock, and tell you if it might have been accidentally reset somehow
 195 2013-01-10 04:22:53 <gmaxwell> petertodd: many bitcoin sites can't seem to bother to invest in secure passwords, so... :P
 196 2013-01-10 04:22:57 <kjj> oh dude.  I was super duper excited the other day when I was reading about chip-scale atomic clocks.  I was thinking they'd be mass produced and cheap.
 197 2013-01-10 04:23:54 <gmaxwell> kjj: I mean, if you want an atomic clock there are 10mhz rubidium standards on ebay for like $80 bucks these days that put out 1pps too.. though a GPSDO will give you much better time.
 198 2013-01-10 04:23:55 <petertodd> by atomic clock standards they have been mass produced and are cheap! I forget who was the supplier, but I looked into it a while back and $1200/unit is now available
 199 2013-01-10 04:24:03 <stealth222> gmaxwell: sure it can be faked out - but the cost to the attacker is significant and is probably not the weakest link in security
 200 2013-01-10 04:24:07 <kjj> turns out that they are around $1500 at quantity.  cheap compared to a cesium fountain, but not "cheap"
 201 2013-01-10 04:24:30 <gmaxwell> http://www.ebay.com/itm/10MHz-Out-FE-5680A-Rubidium-Atomic-Frequency-Standard-Oscillator-Transceivers-/280900901150?pt=LH_DefaultDomain_0&hash=item4166ff991e
 202 2013-01-10 04:24:46 <gmaxwell> ^ there you go, but as said,  a GPSDO gives much better time at all timescales.
 203 2013-01-10 04:25:00 <petertodd> damn, I want that
 204 2013-01-10 04:25:05 <kjj> rubidnium is meh
 205 2013-01-10 04:25:33 <stealth222> why is cesium better?
 206 2013-01-10 04:25:37 <gmaxwell> kjj: I mean a $100-$200 gpsdo puts out better time than a single cesium standard at all timescales too.
 207 2013-01-10 04:25:54 <petertodd> provided you aren't in a cave...
 208 2013-01-10 04:26:24 <stealth222> if you're doing your computing from within a cave, your business practices are already questionable :p
 209 2013-01-10 04:26:39 <gmaxwell> http://www.ebay.com/itm/TRIMBLE-GPS-RECEIVER-10MHZ-CLOCK-THUNDERBOLT-/181052303043?pt=US_Tracking_Devices&hash=item2a278ee6c3 < I have a couple of these, they're great.
 210 2013-01-10 04:26:39 <petertodd> I talked to a guy who found it cheaper to buy the actual atomic clock than it was to pay the costs to get a gps antenna installed in his building
 211 2013-01-10 04:26:45 <kjj> the problem with gpsdo is that you are still trusting the GPS system.  if that goes, your clock goes too
 212 2013-01-10 04:27:04 toffoo has quit ()
 213 2013-01-10 04:27:20 <gmaxwell> kjj: those devices (which have OCXOs) will holdover with >=cesium standard percision for a day.
 214 2013-01-10 04:27:24 <petertodd> yes, but 747's start having near misses so you're clock is the least of their worries :)
 215 2013-01-10 04:27:28 <gmaxwell> Though if GPS _lies_ they'll lie too.
 216 2013-01-10 04:28:23 <stealth222> so use ntp and GPS and your own atomic clock :)
 217 2013-01-10 04:28:25 <petertodd> nice kit, of course do you actually have a use for it?
 218 2013-01-10 04:28:30 <stealth222> and make sure the three agree
 219 2013-01-10 04:28:34 <kjj> check out the SA.45s
 220 2013-01-10 04:28:52 <gmaxwell> petertodd: at the moment, no, but I'd previously used it for surveying very accurate one way latency measurements.
 221 2013-01-10 04:29:12 <stealth222> in any case, attacks based on manipulating the target's clock are probably not the weakest link in the security chain
 222 2013-01-10 04:29:53 <gmaxwell> stealth222: bitcoin clock is kinda nasty, as you can partition the network that way, you just need a lot of IPs. (enough to be more than half the distinct IPs a given node has seen)
 223 2013-01-10 04:30:33 <kjj> the state DOT put survey-accurate GPS receivers in all of the county courthouses a while back.  one of their stated goals was to measure the spread of our part of the north american plate
 224 2013-01-10 04:31:02 <gmaxwell> kjj: yea, they're probably doing RTK gps which can be stupidly accurate.
 225 2013-01-10 04:31:46 <petertodd> you could probably wreck tx propagation by targeting little-used or admined nodes and systematically pushing them off the main chain one by one. I'd consider the 2 hours vs 3 hours an outright design flaw
 226 2013-01-10 04:31:56 <gmaxwell> (you're basically measuring with the GPS carrier, so you can get cm level accuracy as fast as you can collect and process the corrections)
 227 2013-01-10 04:32:05 <kjj> it is a trimble unit, I forget which model.  the antenna mount on the roof is insanely rigid to minimize non-tectonic sway
 228 2013-01-10 04:33:02 <gmaxwell> petertodd: I mean, we could just reduce the network adjustment, but I went around polling nodes (a year and a half ago?) and there were quite a few which were an hour off.
 229 2013-01-10 04:33:16 <gmaxwell> I also reset the network time, which had drifted off UTC a bit.
 230 2013-01-10 04:33:31 <gmaxwell> (by basically performing the aformentioned attack but without the attack part)
 231 2013-01-10 04:33:31 <kjj> heh.  when it broke, I popped it open to disconnect the battery.  the state guys freaked the fuck out when I told them that I fixed it myself
 232 2013-01-10 04:33:56 <petertodd> maybe we could make it a per-os setting? linux is better than windows with daylight savings adjustments in that linux machines are more likely to have system set to gmt
 233 2013-01-10 04:34:22 <gmaxwell> one thing I thought might be worthwhile is that in *nix at least you can find out if you have ntp correction and if ntp thinks its any good.
 234 2013-01-10 04:34:41 <gmaxwell> If it is it could be made more restricted.
 235 2013-01-10 04:34:41 <petertodd> at the very least make a cmd-line switch available to let the user set it down
 236 2013-01-10 04:34:49 <petertodd> good idea
 237 2013-01-10 04:35:03 some_name has quit (Quit: Page closed)
 238 2013-01-10 04:35:05 <gmaxwell> Alternatively, it could do something like accept blocks if they meet 2 hours from _either_ clock.
 239 2013-01-10 04:35:29 <petertodd> so either the system clock, or network clock?
 240 2013-01-10 04:35:34 <gmaxwell> part of the reason that this isn't fixed is that there was no one obvious fix, but lots of sloppy half fixes. :P
 241 2013-01-10 04:35:43 <petertodd> for sure
 242 2013-01-10 04:35:53 <kjj> for a while, when the timing was big news on the forums, I just patched my GetAdjustedTime to return the system time
 243 2013-01-10 04:36:00 <kjj> ^^  half fix
 244 2013-01-10 04:36:19 <petertodd> we should have bitcoin automatically open a ssl connection to http://google.com and extract the timestamp from there... speaking of half fixes
 245 2013-01-10 04:36:29 <gmaxwell> Centeralization yuck.
 246 2013-01-10 04:36:33 <stealth222> lol
 247 2013-01-10 04:37:02 <kjj> I'd rather trust any random node from pool.ntp.org than have to rely forever on a single entity
 248 2013-01-10 04:37:05 <gmaxwell> In any case, going into a safemode and screaming like hell also works with yucky solutions.
 249 2013-01-10 04:37:28 <gmaxwell> kjj: you can pull the time off virtually any ssl server... some are even right!
 250 2013-01-10 04:37:39 <petertodd> so the guys controlling the ntp.org domain name aren't a single entity?
 251 2013-01-10 04:38:22 <petertodd> gmaxwell: I gotta figure out the right steps to make the server return a digest, and I'll add it to my timestamping system as the "shitty-ssl" method
 252 2013-01-10 04:38:27 <kjj> not really, no.  ntp.org is run by time nuts.  they are to timekeeping what goldbugs are to gold.
 253 2013-01-10 04:38:52 <petertodd> so insane and deluded?
 254 2013-01-10 04:39:13 <kjj> passionate about their one thing, to the exclusion of all other reality
 255 2013-01-10 04:39:32 <johzi> sounds like the right group to have it
 256 2013-01-10 04:39:35 <stealth222> well, in their defense, timekeeping is a practical pursuit :)
 257 2013-01-10 04:39:38 <petertodd> a less blunt way to put it...
 258 2013-01-10 04:39:57 <gmaxwell> petertodd: there is a nice tool for ssl time by jacob appelbaum... tails (tor linux distro) uses for tim.
 259 2013-01-10 04:40:00 <gmaxwell> er time.
 260 2013-01-10 04:40:30 <kjj> the NTP protocol is intended to be highly resistant to manipulation.  too bad everyone uses SNTP instead...
 261 2013-01-10 04:40:41 <gmaxwell> stealth222: microsecond precision timekeeping on convention computers not so much.
 262 2013-01-10 04:40:46 <johzi> hehe, look who's saying "centralization yuck"
 263 2013-01-10 04:41:29 <petertodd> ah, teatime and tlsdate, nice!
 264 2013-01-10 04:42:16 <petertodd> I wouldn't call an unsigned and unencrypted protocol like ntp resistent to manipulation, more just tolerant of honest mistakes
 265 2013-01-10 04:43:00 <gmaxwell> petertodd: ntp can in fact be signed.
 266 2013-01-10 04:43:08 <stealth222> what would be the most tamper-resistant distributed timekeeping method? quasars?
 267 2013-01-10 04:43:10 <kjj> unencrypted?  you are thinking early 90s dude
 268 2013-01-10 04:43:15 <gmaxwell> No one bothers. God knows if it works.
 269 2013-01-10 04:43:37 <gmaxwell> stealth222: you need to name their pulses... but they're also hard to observe. Fortunately I solved both problems, at least for insane people.
 270 2013-01-10 04:43:46 <gmaxwell> stealth222: https://people.xiph.org/~greg/decentralized-time.txt
 271 2013-01-10 04:43:53 <petertodd> gmaxwell: the problem with it is that you can't sign a timestamp, it has to be an interactive protocol where you submit a nonce to the server and they reply with a signed timestamp of that nonce
 272 2013-01-10 04:44:16 BlackPrapor has joined
 273 2013-01-10 04:44:19 <gmaxwell> petertodd: they do a signed session key, then the session key is used to encrypt the timestamp.
 274 2013-01-10 04:44:41 <petertodd> gmaxwell: however, come to think of it, what could be done would be to submit your nonce through a merkle-based timestamping system, so all the intermediate servers would take the load off the expensive trusted hardware
 275 2013-01-10 04:44:50 <kjj> gmaxwell: I started reading that the other day.  how impractical is it really?
 276 2013-01-10 04:44:57 BlackPrapor has joined
 277 2013-01-10 04:45:01 BlackPrapor has quit (2!~BlackPrap@77.79.180.160.dynamic.ufanet.ru|Client Quit)
 278 2013-01-10 04:45:04 <petertodd> gmaxwell: exactly, and the session key means every client puts load on the expensive secured server
 279 2013-01-10 04:45:27 <gmaxwell> kjj: needing special hardware makes it impractical. The location stuff at the bottom is impratically, the top stuff could actually be done but wouldn't be used by anything but supernerds.
 280 2013-01-10 04:45:49 <gmaxwell> petertodd: symmetric crypto is stupidly stupidly cheap now. E.g. the AESNI cpus can do like 10gbit .. on one core.
 281 2013-01-10 04:45:56 <kjj> what range do you need to sample?
 282 2013-01-10 04:46:12 <stealth222> symmetric crypto overhead is negligible
 283 2013-01-10 04:46:16 BlackPrapor has quit (Client Quit)
 284 2013-01-10 04:46:53 <petertodd> gmaxwell: yes, but that still means everyone has to talk to the same server, which gets you back to the problem that they won't put the money into it
 285 2013-01-10 04:48:00 <petertodd> gmaxwell: hmm... I wonder if I can hack the ntp protocol somehow along those lines... basically I need to be able to inject digests in the session such that I can get the ntp server to sign them... given it's symetric probably not
 286 2013-01-10 04:48:18 <gmaxwell> kjj: "whatever works best" ... doing visable light sampling may actually work best because you can get so much antenna gain so cheaply... The sun is pretty noisy on all frequencies.   Maybe viable hardware could be a pipe, a reflector, dichroic filter, a photo diode, and a soundcard. Though perhaps atmospheric scattering is just too high, even for near infrared and RF would work better. I wouldn't know without actually trying it.
 287 2013-01-10 04:48:39 <petertodd> gmaxwell: that said, rfc3161 timestamps could work that way as your ntp replacement
 288 2013-01-10 04:49:46 <gmaxwell> petertodd: no no, I just mean that all your pairwise ntp can be authenticated. Actually making time decenteralized secure is hard, but we do actually know how to do it. You have all the nodes observe some centeralized time sources and then use a POW chain to reach a consensus on the offset between the commonly visible osciallator(s) and "time". See the txt I linked above.
 289 2013-01-10 04:50:15 <kjj> heh.  if we made a 1 second mp3 of solar noise and shipped it out, other people could see if it overlapped with their own samples
 290 2013-01-10 04:50:36 <stealth222> mp3 destroys phase information
 291 2013-01-10 04:50:41 <petertodd> gmaxwell: yeah, no I'm purely thinking how to make trusted ntp scalable in a way that can be done now, obviously this idea is still centralized
 292 2013-01-10 04:50:49 <kjj> some phase information, not all
 293 2013-01-10 04:51:00 <gmaxwell> sending it lossless solves that problem. :P
 294 2013-01-10 04:51:44 <kjj> the point is that it needs to be lossy, otherwise it is too much data.  recording clusters of frequency/amplitude/time tuples seems like a reasonable first guess
 295 2013-01-10 04:51:45 <gmaxwell> I'm game to try it sometime— but at the same time, I mostly want to spend my limited free time on things that require no special "stuff" because thy have the greatest ROI.
 296 2013-01-10 04:52:25 <gmaxwell> e.g. for a cipherpunk project I'd rather work on pratical tools for secure sealed auctions, because its just software, than on decenteralized time— even though I like time better it has a hardware component. :(
 297 2013-01-10 04:52:59 <kjj> by passing those packets back and forth, we could eventually train our clocks to agree with each other.  and, if we compare it to various civil time standards, we can eventually agree on how long a second is
 298 2013-01-10 04:53:27 <gmaxwell> kjj: I stream lossless music all the time from archive.org. :P get a bigger pipe.   For a real system what we'd do is the same thing which is done for time space tradeoffs in collission attacks.
 299 2013-01-10 04:53:33 <kjj> rather than a nakamoto chain that burns work to prove extension of the past, we prove extension with the overlap
 300 2013-01-10 04:53:57 <gmaxwell> You take your chunk of sun and run it through some filter which tends to trigger on some signal shapes— distinguished points, and those are what you ship off.
 301 2013-01-10 04:54:06 <stealth222> a consensus-based system rather than a proof-of-work-based system?
 302 2013-01-10 04:54:29 <kjj> well, if I can't overlap your piece with my piece, I know that there is a problem
 303 2013-01-10 04:54:38 WolfAlex has quit (Quit: No Ping reply in 180 seconds.)
 304 2013-01-10 04:54:54 WolfAlex has joined
 305 2013-01-10 04:56:13 WolfAlex has quit (Remote host closed the connection)
 306 2013-01-10 04:57:02 <kjj> the overlap system also has the advantage that it isn't random in the time domain
 307 2013-01-10 04:58:07 <stealth222> fortunately, accurate timekeeping hasn't really been a significant practical problem for most people for a couple centuries :)
 308 2013-01-10 04:58:23 <kjj> as in, I can be pretty sure that I can come up with about a second's worth of solar "points of minutia" every second
 309 2013-01-10 04:59:01 <gmaxwell> stealth222: it's not about accuracy as much on agreeing on the names of the seconds.
 310 2013-01-10 04:59:34 <gmaxwell> an atomic clock gives you phsically accurat time, but it extends forever and every second is the same as every other.
 311 2013-01-10 04:59:41 <stealth222> didn't a 1905 paper pretty much demonstrate that that is impossible?
 312 2013-01-10 04:59:57 <kjj> not at all
 313 2013-01-10 05:00:14 <kjj> at least, not if we are willing to choose a preferred frame
 314 2013-01-10 05:00:26 <stealth222> well, I guess what matters in the end is the count of pulses from a source
 315 2013-01-10 05:00:47 <stealth222> regardless of how much time is perceived between them by different observers
 316 2013-01-10 05:00:50 <gmaxwell> well it's wonky if you're not in the same inertial reference frame, but you can always project on an agreed on one.. but which one? who decides?
 317 2013-01-10 05:01:34 <kjj> solved problem
 318 2013-01-10 05:01:34 <gmaxwell> with a pow chain you can 'securely' (sybil resistant) take a majority (computing power) vote on what is the reference.
 319 2013-01-10 05:01:35 Garr255 has joined
 320 2013-01-10 05:02:05 sgornick has quit (Quit: Ex-Chat)
 321 2013-01-10 05:02:05 <kjj> IERS counts when distant landmarks cross imaginary lines on the earth
 322 2013-01-10 05:02:20 <petertodd> gmaxwell: so essentially you can say that your distributed time thing is about agreeing on the content of a stream of observations, where the agreement is measured by POW voting
 323 2013-01-10 05:02:23 <kjj> all other civil times are derived from their measurements
 324 2013-01-10 05:02:55 <petertodd> gmaxwell: and then interestingly, you're better off making it a true vote, rather than a lucky lottary POW like bitcoin
 325 2013-01-10 05:03:06 <gmaxwell> right. everyone observes, some (if not all) the observations are common to the nodes... and they agree on what they mean.
 326 2013-01-10 05:03:58 maaku has quit (Quit: maaku)
 327 2013-01-10 05:04:06 <gmaxwell> POW sucks... we wouldn't use it in bitcoin except we must because sybil resistance. :(
 328 2013-01-10 05:04:27 <kjj> heh.  that's like "Democracy sucks, but everything else sucks WORSE".
 329 2013-01-10 05:04:43 maaku has joined
 330 2013-01-10 05:04:43 <gmaxwell> Yes.
 331 2013-01-10 05:04:52 <kjj> POS is exactly as bad as it needs to be to solve our problem, no more.  (approximately)
 332 2013-01-10 05:04:53 freakazoid has joined
 333 2013-01-10 05:04:56 <stealth222> gmaxwell: what do you think of the idea of keeping lists of peers trusted not to be in collusion with one another?
 334 2013-01-10 05:05:10 <gmaxwell> if you want to be metaphysical? what is a person? who decides that kjj is one person and not two?  POW removes the problem.
 335 2013-01-10 05:05:13 <kjj> trusted by who?  kept by who?
 336 2013-01-10 05:05:24 <stealth222> trusted by you - kept by you
 337 2013-01-10 05:05:50 <gmaxwell> I too stupid to know that. I generally oppose things I feel that I'm too stupid to use. :P
 338 2013-01-10 05:05:50 <stealth222> not everyone must use the same lists
 339 2013-01-10 05:06:35 <gmaxwell> most people would because they're lazy. ... what for, in any case?
 340 2013-01-10 05:06:55 <stealth222> to avoid the need for a nakamoto chain
 341 2013-01-10 05:07:09 <petertodd> I think it's interesting how if governments issued, say, signed keypairs to the population, you could have a bitcoin-like system with the POW quite literally based on voting (obviously this is centralized at the top level)
 342 2013-01-10 05:07:15 <gmaxwell> it might be fun for a little private thing, but not a global currency.
 343 2013-01-10 05:07:34 <gmaxwell> petertodd: sure, not like a goverment would do anything to inflate a currency. :P
 344 2013-01-10 05:07:34 <petertodd> similarly you could do the same voting trick with trusted computing implementations, one signed key pair per vote
 345 2013-01-10 05:07:55 <kjj> the nice thing about bitcoin is that it attaches a concrete value to key management
 346 2013-01-10 05:07:58 <petertodd> gmaxwell: heh, but at least it'd force them to tip their hand that they were in fact attacking it
 347 2013-01-10 05:08:10 <gmaxwell> (also, go look what we got in the US when people asked for law allowing digital signatures... ugh)
 348 2013-01-10 05:08:13 <johzi> anybody ever had a working idea to solve the double-spending problem, other than by using proof-of-work?
 349 2013-01-10 05:08:24 [7] has quit (Disconnected by services)
 350 2013-01-10 05:08:29 <gmaxwell> petertodd: birthrates really really high in china this year! trust us!
 351 2013-01-10 05:08:33 TheSeven has joined
 352 2013-01-10 05:08:34 <kjj> if the government issued keypairs to everyone for free, key management would be absolutely terrible, and you couldn't trust anything that you didn't know personally
 353 2013-01-10 05:08:56 <petertodd> gmaxwell: or even just "votecoin adoption is going through the roof, look at all the seniors using it!"
 354 2013-01-10 05:08:57 <gmaxwell> johzi: lots of people, mostly by failing to understand how pow solves it and then failing in their own efforts.
 355 2013-01-10 05:09:27 <johzi> i mean working as in not failing
 356 2013-01-10 05:09:40 <gmaxwell> petertodd: you know the average age of votecoin users in japan is now 150! :P
 357 2013-01-10 05:09:40 <petertodd> kjj: why would you assume it'd be terrible? the keypairs could be issued on hardware you know
 358 2013-01-10 05:09:43 <kjj> actually, you are forgetting about the 90s.  back then, it was popular to get around the double spend problem by having a trusted central authority
 359 2013-01-10 05:10:02 <stealth222> I think johzi refers to a distributed approach
 360 2013-01-10 05:10:11 <stealth222> we all know how centralized systems work :p
 361 2013-01-10 05:10:31 <kjj> as far as I know, this is the only working byzantine generals solution
 362 2013-01-10 05:10:36 <johzi> of course. a decentralized system that's not proof-of-work-based
 363 2013-01-10 05:11:09 <petertodd> johzi: prior to bitcoin much of the research investigated systems where a double spend wasn't prevented, but would break the blinding of the anonymized coins in the system
 364 2013-01-10 05:11:17 <stealth222> there are proposals for consensus-based systems using trust relations - but none that I know of that are in operation like bitcoin is
 365 2013-01-10 05:11:19 <gmaxwell> you can have any solution which is based on voting using expendature of a limited resource, if you'd like you can refuse to call that proof of work. :P
 366 2013-01-10 05:11:34 <kjj> petertodd: in that case, the key-device management would be terrible
 367 2013-01-10 05:11:50 <gmaxwell> petertodd: "it does something no one cares about, but hey— its what we could do!"
 368 2013-01-10 05:12:31 dg10050 has joined
 369 2013-01-10 05:13:23 <petertodd> since bitcoin now does exist, a plausible way of doing a pow chain is now to tie the pow to throwing away bitcoins in fees, the block with the most fees wins, or even do it on a transaction level
 370 2013-01-10 05:13:38 <gmaxwell> if you want do so something sexy, do this— figure out how to create a timelock crypto system where all timelock puzzles can be worked on with O(1) effort. Then make a proof of work cryptocoin based on advancing the timelock clock.
 371 2013-01-10 05:13:55 <gmaxwell> Then we get both timelock crypto and a currency with one unit of energy spent.
 372 2013-01-10 05:14:41 <stealth222> lol @ sexy. it is certainly an interesting intellectual problem - but I'm not sure that solving it will get you laid :p
 373 2013-01-10 05:14:52 <kjj> well...  we could simply refuse to accept blocks until 10 minutes have passed since the last one, and leave difficulty at 1
 374 2013-01-10 05:15:24 <gmaxwell> kjj: very very very long convergence times there.
 375 2013-01-10 05:15:43 <deano> how to tell when 10 minutes has passed? can forge in block
 376 2013-01-10 05:15:43 <petertodd> gmaxwell: oh, so you mean essentially make the pow problem cracking timelock puzzles to make it into a useful computation?
 377 2013-01-10 05:15:45 <gmaxwell> (go look at the lolcoin that fixed their difficulty a 0.05)
 378 2013-01-10 05:15:54 <kjj> oh.  heh, I didn't see that in your first post.  :)
 379 2013-01-10 05:16:18 <gmaxwell> petertodd: yea, most attempts to make pow useful make it not useful as pow, but I suspect that if a generalizable timelock is possible it wouldn't break the powness.
 380 2013-01-10 05:16:30 <petertodd> gmaxwell: I guess you basically need a timelock algorithm where intermediate work can be verified, and in addition you can replace the puzzle with a nonce if there is no real work to be done
 381 2013-01-10 05:16:56 <petertodd> there's timelocks based on hashing, so it's probably plausible
 382 2013-01-10 05:17:45 B0g4r7__ has joined
 383 2013-01-10 05:17:59 <gmaxwell> imagine something like, somehow you securely produce a random ECC public key.  You time lock encrypt to it by doing ECDH against it. Now the network attacks the timelock by doing pollard rho to break the key, and publishes distinguished points along the way to mine blocks.
 384 2013-01-10 05:18:18 <gmaxwell> when you get the solution, everything is unlocked and you go to the next block.
 385 2013-01-10 05:18:39 <gmaxwell> so where do you get the random keys from? maybe they are the hex expansion of pi.
 386 2013-01-10 05:18:41 <stealth222> I likE THAT :)
 387 2013-01-10 05:19:04 <gmaxwell> oh did I just solve this? neat.
 388 2013-01-10 05:19:10 <petertodd> gmaxwell: that sounds really cool, but also reminds me I should have gone for something harder than a fine arts degree... :P
 389 2013-01-10 05:19:30 <petertodd> ha, pi hex expansion, lovely
 390 2013-01-10 05:20:00 <kjj> who produces these public keys?
 391 2013-01-10 05:20:03 <petertodd> of course you could equally just do a prng seeded with a timestamped genesis block
 392 2013-01-10 05:20:29 <gmaxwell> kjj: pi does.
 393 2013-01-10 05:20:44 <stealth222> and it has the added benefit of computing pi :)
 394 2013-01-10 05:20:47 <gmaxwell> or as petertodd says.. though you need to just feel confident that there is nothing up their sleeve.
 395 2013-01-10 05:21:05 <gmaxwell> thats generally the problem in making pow do useful work— the risk that there is a trapdoor on the work.
 396 2013-01-10 05:21:15 B0g4r7 has quit (Ping timeout: 276 seconds)
 397 2013-01-10 05:21:15 B0g4r7__ is now known as B0g4r7
 398 2013-01-10 05:21:16 <stealth222> practically any computable irrational number would probably do
 399 2013-01-10 05:21:33 <stealth222> even .101001000100001000001....
 400 2013-01-10 05:21:42 <kjj> you need your slices of pi (I prefer tau over pi, actually, but whatever) to depend on the previous solution
 401 2013-01-10 05:22:08 <petertodd> there is the practical problem that now you need code that computes pi in every implementation, better just to use a simple stream cipher
 402 2013-01-10 05:22:17 <petertodd> er, I man stream prng
 403 2013-01-10 05:22:18 <stealth222> well, not that one because after a while all the bits in a frame are zero
 404 2013-01-10 05:22:21 <kjj> otherwise, people will pre-compute, since pre-computation is the only practical way for anyone except the fastest guy to participate
 405 2013-01-10 05:22:42 <stealth222> yeah, the next puzzle has to be based on the solution to the previous one
 406 2013-01-10 05:22:49 <gmaxwell> oh darn right, see this is why I didn't already do that.
 407 2013-01-10 05:23:15 <gmaxwell> oh wait.
 408 2013-01-10 05:23:23 <stealth222> it's still possible
 409 2013-01-10 05:23:33 <gmaxwell> So you make your pollard rho step depend on the block header hash.
 410 2013-01-10 05:23:40 <stealth222> xor the solution to the previous puzzle with the next random number
 411 2013-01-10 05:23:54 <gmaxwell> stealth222: no then you can't encrypt with that in advance to use it as a timelock
 412 2013-01-10 05:24:13 <gmaxwell> The idea of this is so that it POWs and lets people encrypt stuff that can only be decrypted in the future.
 413 2013-01-10 05:24:35 <stealth222> yes, I get it - point is nobody knows the public key for the next puzzle until the previous one is solved
 414 2013-01-10 05:24:38 <petertodd> well their timelock now just has to be based on one of the prior blocks basically
 415 2013-01-10 05:24:44 <stealth222> hmm
 416 2013-01-10 05:26:47 <gmaxwell> petertodd: to do the POW chain your POW has to be based on your current block too, so the idea is is there a way to crack an asymmetric cipher which a prng key but which is also based on a current starting point. I think so— because you can use a randomized cracking algorithim that starts/advances based on your header hash. But you need a proof that you did that, and it needs to be cheap to verify and compact.
 417 2013-01-10 05:27:01 maaku has quit (Quit: maaku)
 418 2013-01-10 05:27:01 <gmaxwell> and thats too much math to worry about at midnight for me. :)
 419 2013-01-10 05:27:02 <kjj> has the problem that the guy with his CPU dipped in liquid nitrogen is going to mine every block, and no one else will ever get any
 420 2013-01-10 05:27:20 <petertodd> ha, it'd be ok if for some reason there was a real need for timelocks only 10 minutes long
 421 2013-01-10 05:27:29 <petertodd> I kinda don't see the market there though...
 422 2013-01-10 05:28:00 <gmaxwell> yea, 10 minute timelocks are boring. Ten year ones are neat.
 423 2013-01-10 05:28:18 <gmaxwell> year to 10 year timeframes have interesting public policy implications.
 424 2013-01-10 05:28:22 <petertodd> of course, the ten years assumes constant timecoin mining power
 425 2013-01-10 05:28:33 <kjj> hashing has amazing properties, that just perfecely fit with bitcoin's needs
 426 2013-01-10 05:28:43 <gmaxwell> petertodd: you can have timecoin agree to advance problems only so often to make it predictable in fact.
 427 2013-01-10 05:29:24 <petertodd> no, I don't think that works, because if they're doing that you can't know exactly what problem they will be solving, and hence you can't encrypt to that problem
 428 2013-01-10 05:29:41 <gmaxwell> petertodd: e.g. it might crazy a problem early, so it just stays on the problem until the next problem's time. I don't mean by adjusting the problem difficulty.
 429 2013-01-10 05:30:08 da2ce704 has quit (Ping timeout: 240 seconds)
 430 2013-01-10 05:30:30 <petertodd> oh, so basically now you have a list of problems by *time*, and you say that if hashing is going fast you work on a different problem?
 431 2013-01-10 05:30:40 paraipan has quit (Quit: Saliendo)
 432 2013-01-10 05:31:14 <petertodd> so now your block database has to be partial solutions to any one of however many problems
 433 2013-01-10 05:32:08 <petertodd> see, since that is a parallel problem, you might still be able to avoid the precomputation problem, just have enough problems in the set that miners have a decent chance of not doign other miners work
 434 2013-01-10 05:33:11 <petertodd> it's work as a way of provably expending work, and then use those work tokens in, say, a randomized voting system or something
 435 2013-01-10 05:33:53 <gmaxwell> Careful you don't get the proof of stake problem there. :(
 436 2013-01-10 05:34:21 <petertodd> yeah, I'm not sure you can use for for transaction ordering
 437 2013-01-10 05:34:32 <petertodd> you could use it as a way of establishing trust though
 438 2013-01-10 05:35:09 <petertodd> timestamp each pow you perform to show that at moment whatever you did that, and thus you can compute the value (relative to difficulty) at the time
 439 2013-01-10 05:36:13 <petertodd> basically solving these problems is a coin distribution system actually
 440 2013-01-10 05:36:16 maaku has joined
 441 2013-01-10 05:36:27 <petertodd> for a currency whose inflation is purely total mining power
 442 2013-01-10 05:36:34 jurov has quit (Ping timeout: 260 seconds)
 443 2013-01-10 05:36:44 <petertodd> which is exactly why it can easily turn into proof of stake...
 444 2013-01-10 05:36:46 <kjj> ugh.  why are website designers so thoughtless?
 445 2013-01-10 05:37:24 <petertodd> although... with timestamps you can still do ordering, problem is, you need a bitcoin pow system for the timestamps...
 446 2013-01-10 05:37:48 <kjj> I double click in putty to get a txid, quotes come along for the ride.  paste into blockchain.info (or most other sites), and it says it can't find those firstbits
 447 2013-01-10 05:38:17 <petertodd> like, imagine a currency whose transaction ordering rule is purely "show me a timestamp linked to the bitcoin block", and now coin distribution is done by the timelock problem
 448 2013-01-10 05:38:26 jurov has joined
 449 2013-01-10 05:38:57 <petertodd> (obviously such a rule could lead to some nasty tx invalidation attacks, but maybe there is still a use for it)
 450 2013-01-10 05:39:15 <gmaxwell> petertodd: yea, bitcoin _does_ give more yeld than bitcoin itself. In general you can make secure oracles that do amazing things when you feed them chunks of blockchain.
 451 2013-01-10 05:39:20 <kjj> petertodd: at least then you still only need one POW system, and it can protect all of the other systems for free
 452 2013-01-10 05:39:38 <petertodd> absolutely, merged mining is just the beginning
 453 2013-01-10 05:40:03 <gmaxwell> That was really the big innovation of merged mining— showing that you can combine them all, while leaving them independant, and also without adversly impacting the scaling of bitcoin.
 454 2013-01-10 05:40:09 Hashdog has joined
 455 2013-01-10 05:40:25 <gmaxwell> It also means that the bitcoin POW may actually have enough strength to be secure even if bitcoin mostly fails as a currency, which is a surprising outcome.
 456 2013-01-10 05:40:48 <petertodd> yeah, it's sad to see so many alt-coins ingnoring merged mining, which really shows how their for-miner scamcoins
 457 2013-01-10 05:41:17 <petertodd> yup, enough of these apps and there will be plenty of mining power way off into the future
 458 2013-01-10 05:41:29 <JohnGalt2> is there mergedmining for btc/ltc?
 459 2013-01-10 05:41:29 <kjj> I think we'd need a HUGE increase in alt-coin utility for any part of the ecosystem to be able to support the chain, even at today's modest security levls
 460 2013-01-10 05:41:32 <petertodd> similarly fidelity bonds like I proposed are another example
 461 2013-01-10 05:41:42 <kjj> JohnGalt2: no
 462 2013-01-10 05:41:43 <gmaxwell> There is a bootstrapping problem with merged mining though, one result of merged mining is that while your chain is worthless, bitcoin miners can attack it for free. :P
 463 2013-01-10 05:41:59 <kjj> LTC is intentionally incompatible
 464 2013-01-10 05:42:11 <gmaxwell> kjj: Yea, perhaps not likely but _possible_ which is surprising and interesting.
 465 2013-01-10 05:42:29 <gmaxwell> LTC was made incompatible so it would be impossible to GPU mine. (::snerk::)
 466 2013-01-10 05:42:36 <kjj> well, the solution to bitcoin mininers attacking alt chains it to stop making worthless alt chains
 467 2013-01-10 05:42:43 Hashdog has left ()
 468 2013-01-10 05:42:50 <JohnGalt2> but there is gpu mining now for ltc?
 469 2013-01-10 05:42:59 <kjj> yeah, they did it wrong
 470 2013-01-10 05:43:07 <petertodd> yup, the pow problem is scrypt, but with parameters set such that gpu's are feasible
 471 2013-01-10 05:43:10 <JohnGalt2> oh that's why lol, thx
 472 2013-01-10 05:43:11 <kjj> still incompatible, but not incompatible enough to meet their stated goals
 473 2013-01-10 05:43:22 <petertodd> scrypt = memory hard pow algorithm basically
 474 2013-01-10 05:43:24 <gmaxwell> And sooommmeeeee people were saying that was wrong all along, but not like I know any of those pople.
 475 2013-01-10 05:43:53 <kjj> LTC is gonna crash this year
 476 2013-01-10 05:44:09 <gmaxwell> GPUS have lots of very fast memory too, trying to evade gpus with memoryhardness is kinda silly generally (yes, you could set the scrypt parameters to make it harder, but the idea is not very swift)
 477 2013-01-10 05:44:21 <kjj> ASICs will push GPUs out of bitcoin, and into whatever they can be used for
 478 2013-01-10 05:44:33 <stealth222> playing games? :)
 479 2013-01-10 05:44:39 <JohnGalt2> :D
 480 2013-01-10 05:45:00 <petertodd> and if anything, you *want* your cryptocurrency to be asic minable, so that "spur-of-the-moment" attacks are as hard as possible (IE renting general purpose computers to attack a chain)
 481 2013-01-10 05:45:12 <kjj> are you mad?  bitcoin gpus aren't good for gaming.  they are years out of date and have racked up more fan spins than any gaming rig will see in a decade
 482 2013-01-10 05:45:35 <stealth222> point is that was their originally intended market
 483 2013-01-10 05:45:35 <kjj> often at out-of-spec temperatures and voltages too
 484 2013-01-10 05:45:55 <stealth222> bitcoin piggybacked on an existing market and the economies of scale involved
 485 2013-01-10 05:46:04 <gmaxwell> petertodd: yup. though you can't fight asics you can only limit their speedup, but they'll always be the most efficient way to mine.
 486 2013-01-10 05:46:10 <stealth222> ASICs have the economy of scale issue still
 487 2013-01-10 05:46:46 <kjj> there are (heh, maybe) 4 ASIC projects nearing completion soon
 488 2013-01-10 05:47:00 <gmaxwell> Luke made a neat argument that having gpu resistance is bad because it means the asic gap is wider (over cpus) than with something in the middle. ... meaning an attacker with early asics is more damaging.
 489 2013-01-10 05:47:05 <stealth222> there just isn't a large enough market for dedicated mining hardware to make costs sufficiently low to compete with GPUs yet
 490 2013-01-10 05:47:17 <stealth222> although ASICs are a better technology for mining
 491 2013-01-10 05:47:44 <kjj> you know that the bitcoin system has dumped somewhere north of a million dollars into ASIC development right?
 492 2013-01-10 05:47:53 <gmaxwell> stealth222: the fpga stuff has been superior in $/MH and J/MH for a year now.
 493 2013-01-10 05:48:02 <petertodd> gmaxwell: simple pow problems do make it easier to get asics sooner though, an asic for a memory hard problem might be plenty fast, but the up-front-development cost could be huge
 494 2013-01-10 05:48:23 <petertodd> kjj: could easily more more like ten million
 495 2013-01-10 05:48:27 <gmaxwell> petertodd: it's not like memory is actually hard to design.
 496 2013-01-10 05:49:00 <kjj> 10 million might be market demand, but I double that the 4 projects have actually put much more than a million or two into ASIC development and production
 497 2013-01-10 05:49:01 <gmaxwell> 1m sounds high, access to 110-130nm is cheap. Access to 65nm on mpw is not insanely expensive. (though long ass leadtimes)
 498 2013-01-10 05:49:15 <petertodd> gmaxwell: no, but the point is to do a speed up you need expensive small processes, which makes the first usable asic expensive
 499 2013-01-10 05:49:42 <gmaxwell> petertodd: Good point. Right, you don't get a usuable speedup on memory hard problems without being on a compariable process.
 500 2013-01-10 05:49:44 <petertodd> look at how the bitcoin pow was simple enough that a competitive asic was done by artfonz really early on
 501 2013-01-10 05:49:49 <kjj> gmaxwell: don't forget to multiply by 3 and add the license cost for bASIC's 3rd party core
 502 2013-01-10 05:49:54 <petertodd> gmaxwell: exactly
 503 2013-01-10 05:50:34 <petertodd> the best pow should be as close to a simple counter as is cryptographically secure
 504 2013-01-10 05:50:35 <stealth222> the mining market is also self-limiting
 505 2013-01-10 05:50:44 <gmaxwell> petertodd: I do feel sad that we missed a really nice window.
 506 2013-01-10 05:50:46 <stealth222> the larger it becomes, the greater the difficulty
 507 2013-01-10 05:50:59 <petertodd> missed a window?
 508 2013-01-10 05:51:19 <kjj> stealth222: most of reality is like that.  everything you see around you is a balance of opposing forces
 509 2013-01-10 05:51:30 <stealth222> yes, it's a feature of bitcoin - not a flaw
 510 2013-01-10 05:51:36 <stealth222> but it has implications for microelectronics
 511 2013-01-10 05:51:45 <stealth222> and the economies of scale thereof
 512 2013-01-10 05:51:49 <gmaxwell> Bitcoin could really have bootstrapped computing as a commodity, you build a gpu farm to run whatever people pay you for— mine bitcoin when its idle.  The fact that you can mine bitcoin takes the risk of of building it. And we never got it because either there isn't yet enough demand for computing as a commodity, or.. no one was interested in writing the software for it. :(
 513 2013-01-10 05:52:06 <petertodd> ah right, yeah
 514 2013-01-10 05:52:18 <kjj> everyone that needs tons of GPUs already has them
 515 2013-01-10 05:52:30 <phantomcircuit> gmaxwell, that's what coinlabs is trying to do
 516 2013-01-10 05:52:36 <phantomcircuit> i strongly suspect they will fail
 517 2013-01-10 05:52:41 <kjj> and the radeon's uncanny suitability to bitcoin is a freak accident
 518 2013-01-10 05:52:53 <petertodd> still, I dislike that idea because it implies there is lots of bitcoin-capable computing power out there just waiting to be rented by an attacker
 519 2013-01-10 05:53:06 <gmaxwell> kjj: I'd but _lots_ of computing power if I could buy it at near electrical prices.
 520 2013-01-10 05:53:10 <kjj> out there, yes.  rentable, meh
 521 2013-01-10 05:53:21 <gmaxwell> especially if I could buy it in 5-10 minute chunks.
 522 2013-01-10 05:54:10 <kjj> turns out that the limit isn't the computing or the power, but the management
 523 2013-01-10 05:55:35 <petertodd> the big market isn't rentable computing power, it's rentable disk space, io bandwith, and network bandwith
 524 2013-01-10 05:55:39 <gmaxwell> (I have 160 opteron cores here, and would gladly pay a premium of— say— 2x power cost to get my 160/cores/week in 5 minutes)
 525 2013-01-10 05:56:12 <petertodd> how did you wind up with 160 operton cores?!
 526 2013-01-10 05:56:41 <kjj> that's like a quarter rack.  not that big of a deal, really
 527 2013-01-10 05:57:17 <petertodd> hmm... true, I keep forgetting I haven't looked at computer hardware prices since early 2000...
 528 2013-01-10 05:57:23 <kjj> erm, just realized that I may have a slightly warped perception
 529 2013-01-10 05:57:31 <gmaxwell> a suspicious ebay auction that turned out not to be a scam... someone listed 10x opteron 8356's for $400. what the hell.. I'll buy.. figuring I'd be disputing the paypal... they show up and work.
 530 2013-01-10 05:57:34 <kjj> several friends work at Cray
 531 2013-01-10 05:57:37 <gmaxwell> "How many more of these do you have?"
 532 2013-01-10 05:57:48 <petertodd> crazy
 533 2013-01-10 05:57:51 <gmaxwell> And I haggled him down on the price too.
 534 2013-01-10 05:58:29 <gmaxwell> I note they shipped from oak ridge tn. And this was shortly after the jaguar supercomputer was upgraded from 4 to 6 core chips. So I suspect these might hav come out of that process.
 535 2013-01-10 05:58:32 <petertodd> and here I am with one 4 year old computer and a crap laptop
 536 2013-01-10 05:59:00 <petertodd> interesting! fell of the back of a truck leaving the facility?
 537 2013-01-10 05:59:14 <kjj> ha!  you got a batch of the Jaguar CPUs.  All I got was the lousy t-shirt
 538 2013-01-10 05:59:37 <gmaxwell> maybe! or what does cray officially do with the things after an upgrade? who knows.
 539 2013-01-10 06:00:03 <gmaxwell> I have actually resisted seeing if the 6core ones showed up on ebay now that they've upgraded again.. they'd work in my motherboards....
 540 2013-01-10 06:00:06 <kjj> federal facility.  they were sold to a "recycler" for a song, the recycler resold them
 541 2013-01-10 06:00:15 <gmaxwell> I don't need any more power draw...
 542 2013-01-10 06:00:16 <stealth222> I know someone in the electronics recycling business - stuff that doesn't have resell value as electronics is harvested for raw materials
 543 2013-01-10 06:00:47 <gmaxwell> Yea, I was only even looking on ebay because high end cpus sometimes go insanely cheap, but that was the first time I'd see any _quantity_ of them show up that way.
 544 2013-01-10 06:00:50 <kjj> government agencies have funny rules about disposal
 545 2013-01-10 06:01:41 <kjj> I have to get board approval to dispose of anything that ever had a value of more than $500.  just as an example
 546 2013-01-10 06:02:17 <kjj> and we can't do anything useful with the stuff when we dispose of it, lest someone think we are showing favor to some person or vendor.
 547 2013-01-10 06:02:19 <petertodd> I take it that's purchase value isn't it?
 548 2013-01-10 06:02:37 <kjj> yeah, with IT stuff, purchase price is usually the max it'll ever be
 549 2013-01-10 06:03:02 <petertodd> I was about to say, "accidentally" drop the stuff down a flight of stairs to get the value down...
 550 2013-01-10 06:03:51 <petertodd> so reselling the equipment to dispose of it made difficult then 'eh?
 551 2013-01-10 06:03:51 <kjj> easier to pack it into a room for another year.  most of my stuff has negative value when I sell it because the hassle of taking it apart exceeds the recycle value
 552 2013-01-10 06:04:13 <kjj> er, dispose of, not sell.  selling is too much hassle
 553 2013-01-10 06:05:20 <kjj> my board is cheap, and I'm frugal, so I tend to run stuff until it really is valueless.  on the other hand, the cops get forfeiture, and they sell it at auction.
 554 2013-01-10 06:05:52 <kjj> if I ever needed to get rid of stuff that was still useful, I'd get the board to approve letting them auction it off.  but that's so rare
 555 2013-01-10 06:06:07 <petertodd> ah, makes sense
 556 2013-01-10 06:06:13 <petertodd> yeah, sounds like a lot of paperwork
 557 2013-01-10 06:06:43 <gmaxwell> kjj: I spent many years working for a county goverment. I looked back to IRC and was confused that I didn't remember typing the stuff on the screen. :P
 558 2013-01-10 06:07:04 <gmaxwell> well. many is like 6, but it was a decade ago so it seem like a long time.
 559 2013-01-10 06:07:34 <kjj> one time I did get approval to donate to a local charity.  they work with disabled people, and the guy that runs it is pretty sharp, so he tinkers.  keeps a lot of old gear running.  we found a stash of super old junk, turned out to be perfect for him
 560 2013-01-10 06:07:36 <petertodd> heh, I've only ever worked at startups, so I still know nothing of bureaucracy
 561 2013-01-10 06:08:26 <kjj> every now and then, I feel like I should get back out into the real world and find productive work.
 562 2013-01-10 06:08:45 <gmaxwell> we stuffed stuff we wanted to dispose of in a warehouse and it would go out in an annual auction.
 563 2013-01-10 06:09:08 <petertodd> gmaxwell: at least that's efficient-ish...
 564 2013-01-10 06:09:11 <gmaxwell> And there was no rule against staff going to the auctions (it was encouraged in fact).  .... I got a lot of random stuff that way.
 565 2013-01-10 06:09:26 <kjj> but things are such a mess on all levels that I usually find enough savings, direct or indirect, to pay my salary in the first half of the year.
 566 2013-01-10 06:09:40 <gmaxwell> Including a lot of stuff where other people bought lots and took one think and they gave me the rest (there was a removal rule)
 567 2013-01-10 06:10:53 <kjj> our state laws have cleared up a lot recently, but our local policies are lagging.  so it is harder for us than it needs to be.  oh, and the auditors have their own calendars, so I can blame a lot of it on them insisting that we follow rules that we don't really need to follow
 568 2013-01-10 06:10:59 <gmaxwell> kjj: yea, I paid my salary multiple times over every year I was there. Actually, I almost saved my entire income for my duration there with a single project. (an audit of our phone bills)
 569 2013-01-10 06:11:53 <gmaxwell> we had crap like 56k leased lines running out to facilities that the county hadn't occupied in a decade.... all over the place... banks of phonelines to buildings that were demolished...
 570 2013-01-10 06:12:51 <kjj> ugh
 571 2013-01-10 06:13:04 <gmaxwell> dozens of phone lines at ... totally random residences we were paying for .. for no explicable reason, even theft by staff couldn't explain it...
 572 2013-01-10 06:13:21 <kjj> my county is pretty small, so I don't have enough of that sort of thing to go on
 573 2013-01-10 06:14:12 <gmaxwell> Well, we only had about 8000 lines in total... but in a lot of seperate buildings.
 574 2013-01-10 06:14:29 <petertodd> reminds me of the one job I have had at a big institution: working as a lab monitor at my university. I found out 6 months after I was hired that my boss, who I had never met, didn't know I had been hired and had been signing my timesheets anyway... we had a *lot* of payroll fraud
 575 2013-01-10 06:14:39 <gmaxwell> a lot of the cost I saved was in the random leased lines, alarm circuts, dry copper, and other crazy stuff that had just been abandoned.
 576 2013-01-10 06:14:48 <kjj> but I'm involved in a lot of state-wide efforts.  I think I paid for myself a dozen times over last year by doing simple math on the pricing model proposed by a vendor during contract negotiations
 577 2013-01-10 06:15:28 <kjj> when you were done with your audit, how many lines were you down to?  200?
 578 2013-01-10 06:15:47 balrog has quit (Ping timeout: 255 seconds)
 579 2013-01-10 06:15:52 <gmaxwell> haha. no.
 580 2013-01-10 06:16:23 <gmaxwell> I left there to go work at an equipment manufacturer, and oh man, if I knew before what I knew now I would have saved a lot more money. (the discount is what? hah. Try again. This time with the chassis for free please)
 581 2013-01-10 06:16:27 da2ce7 has joined
 582 2013-01-10 06:17:34 <kjj> yeah.  IT gear is like that.  other stuff too, I suppose, but I don't see it so much
 583 2013-01-10 06:19:00 <kjj> I have a cousin that does IT for the air force.  when we swap stories, it usually ends with me crying.  they spend more on Cisco maintenance agreements in his department than my entire budget.
 584 2013-01-10 06:19:05 dg10050 has quit (Quit: dg10050)
 585 2013-01-10 06:19:57 <kjj> which totally made sense, 10-15 years ago when Cisco was the only company that could do the stuff that needed to be done.
 586 2013-01-10 06:21:02 <gmaxwell> I saved a ton switching most of the network gear to sw support from next-day support, and self spared... and then had failure rates a tiny fraction of my projections too.
 587 2013-01-10 06:21:50 <kjj> heh.
 588 2013-01-10 06:23:49 <kjj> hey, before I go to bed, let me ask you how much you've thought about coin mixing
 589 2013-01-10 06:24:38 <kjj> it seems to me that with the raw API and some scripts, making a semi-automatic payment mixer is just a matter of doing, not of figuring out how to do
 590 2013-01-10 06:25:23 AtashiCon has quit (Quit: AtashiCon)
 591 2013-01-10 06:25:56 <gmaxwell> Correct. I actually reviewed some tor hidden service for someone a while back that would have acted as a meeting middle point for this.  (the idea is you tell it your inputs, it drafts a transaction everyone signs)  But it seems to have never materalized.
 592 2013-01-10 06:26:34 <kjj> the tricky part would be the user side
 593 2013-01-10 06:26:44 balrog has joined
 594 2013-01-10 06:26:57 <kjj> and by tricky, I mean I don't want to be responsible for having it accept things automatically
 595 2013-01-10 06:27:20 <gmaxwell> I'd rather have something that worked by finding partners for transactions so you don't even increase the transaction count.. and some of the payees in the transaction are actual payees.
 596 2013-01-10 06:27:49 <kjj> right
 597 2013-01-10 06:27:55 <gmaxwell> but yes, it's all UI. not science.
 598 2013-01-10 06:27:58 <kjj> and I'm not sure that non-payment mixers are useful
 599 2013-01-10 06:28:36 <kjj> as in, the real benefit is when you and someone else that both want to send 1 BTC pair up, meld your 2 BTC together in one transaction, and go
 600 2013-01-10 06:29:13 <gmaxwell> I think more mixing is better than bigger mixing for sure...
 601 2013-01-10 06:29:20 <kjj> tossing coins in a bucket and getting different ones out seems like a bad move.  you'll recombine them with your other wallet eventually
 602 2013-01-10 06:29:28 <petertodd> kjj: did you read my latest fidelity bonds post? https://bitcointalk.org/index.php?topic=134827.0
 603 2013-01-10 06:29:48 <petertodd> I really think a totally off-chain system is workable, and it doesn't need to have the complexity that opentransactions does
 604 2013-01-10 06:29:50 <kjj> yup, I read it
 605 2013-01-10 06:30:05 <gmaxwell> kjj: thats an excellent point, though it would happen less if the client was smart enough to resist cross linking.
 606 2013-01-10 06:30:18 <kjj> the problem is that you are using a real world term, but not in the way that the real world uses it
 607 2013-01-10 06:30:28 <petertodd> the fidelity bonds bit?
 608 2013-01-10 06:30:40 <petertodd> which aren't even bonds, they're insurance in the real world...
 609 2013-01-10 06:30:54 <kjj> gmaxwell: resistance always fails eventually
 610 2013-01-10 06:31:20 <kjj> a day will come when you have to empty your wallet, and when that day comes, all of the threads come back together
 611 2013-01-10 06:31:35 <kjj> petertodd: well, sorta
 612 2013-01-10 06:32:07 <petertodd> a big part of why I think the idea can work is precisely because of how much people are already happen with stuff like instawallet and torwallet
 613 2013-01-10 06:32:37 <kjj> petertodd: usually, the bonded entity doesn't put up the cash for their bond, they pool it.  but in your thing, at no time is that funding ever available to the person that you didn't perform for
 614 2013-01-10 06:33:26 <kjj> also, I think that there are better ways to cultivate a reputation than to gift (or burn) money
 615 2013-01-10 06:33:40 <petertodd> no, but fundementally a decentralized system just can't keep secrets to give the funds back, had the bitcoin transaction rules included the idea, you could do it, but they don't so you can't
 616 2013-01-10 06:34:30 <petertodd> it's not cultivating a reputation, it's provably putting yourself into a position where a rational economic actor will be honest
 617 2013-01-10 06:34:36 AtashiCon has joined
 618 2013-01-10 06:34:55 <gmaxwell> kjj: there are other neat things that can be done. E.g. what if a checkbox let you make a payment in multiple transactions, if doing so prevented linking?   What if a checkbox let you round up payments to some specified amount if doing so prevents change (which is a weaker linking risk in the future)?  (e.g. paying into bank like accounts)
 619 2013-01-10 06:35:16 <kjj> our entire economic system is based on the idea that no financial transaction is ever final.  this is a very corrosive way to live, because it makes it very hard to imagine how a sane world would work
 620 2013-01-10 06:35:19 Arnavion has quit (Quit: Arnavion)
 621 2013-01-10 06:36:15 <petertodd> basically fidelity bonds value transfer is somewhere between torwallet and bitcoin in terms of assurance that you won't be defrauded
 622 2013-01-10 06:36:22 nus has quit (Ping timeout: 276 seconds)
 623 2013-01-10 06:36:38 <gmaxwell> I'm skeptical of fiedlity bonds for this, and I also think that at the moment charity (non-mining) donations are a better provable cost.
 624 2013-01-10 06:36:39 <kjj> petertodd: that only defends against premeditated dishonesty.  not a bad thing, but the trend lately has been to make mistakes, and then run away.  if the bond cost is already sunk, it doesn't stop the flight with whatever they have
 625 2013-01-10 06:36:50 <gmaxwell> We don't need more mining incentive right now.
 626 2013-01-10 06:36:57 <petertodd> kjj: we're even disputing value transfers made 300 years ago between governments and natives...
 627 2013-01-10 06:37:46 <petertodd> kjj: and that's fine, for coin mixing having people run away from their services because they screwed up is no worse than the existing system
 628 2013-01-10 06:37:49 <kjj> heh.  those were in dispute from day one
 629 2013-01-10 06:37:57 <gmaxwell> petertodd: look at pirate40, he made a 5000 BTC bet with someone that he wouldn't default and then defaulted. Hell, the default conditions were so weak he could have delayed it a long time too. Thats one hell of a fidelity bond there.
 630 2013-01-10 06:38:16 <petertodd> gmaxwell: yes, but it was a fidelity bond with a value less than what he owed
 631 2013-01-10 06:38:18 <gmaxwell> (5000 btc bet with funds in excrow, the better won)
 632 2013-01-10 06:38:32 <petertodd> the idea has to be used properly to work
 633 2013-01-10 06:38:39 <gmaxwell> petertodd: you think people should fidelity bond for greater than they'd owe for businesses? 0_o
 634 2013-01-10 06:38:53 <gmaxwell> (well for _depository businesses_)
 635 2013-01-10 06:39:07 <kjj> sometimes, leaving the railing off is the best move.
 636 2013-01-10 06:39:08 <petertodd> absolutely, that's the whole point, they're for how much you have on deposit at any one time, and you have to wait a while to collect enough fees to make it worth it
 637 2013-01-10 06:39:27 <petertodd> *they're for a multiple of how much you have
 638 2013-01-10 06:39:59 <petertodd> just set the expiry time of your offers such that you get the return on capital that you want
 639 2013-01-10 06:40:22 <kjj> people are absolutely fucking terrible at assessing risk.  a 100 BTC bond will make 1000 people each think that you are good for 10 BTC
 640 2013-01-10 06:41:07 <petertodd> which is why you automate the process of determining if the issuer has the right incentives, it only works if you can determine the total deposits at any time, which is easy in bitcoin
 641 2013-01-10 06:41:16 <gmaxwell> hah
 642 2013-01-10 06:41:19 <petertodd> basically this *must* be done with software
 643 2013-01-10 06:41:35 <petertodd> it is easy when you advertise what deposit addresses are being used publicly
 644 2013-01-10 06:41:40 MrTiggr has quit (Ping timeout: 265 seconds)
 645 2013-01-10 06:41:43 <gmaxwell> and then everyone will go put their bitcoins in a single website in any case. :P
 646 2013-01-10 06:41:56 <petertodd> which is fine if the website has posted a big enough bond
 647 2013-01-10 06:41:58 <kjj> and also withdrawal addresses.  :)
 648 2013-01-10 06:42:03 <kjj> and cold wallet addresses
 649 2013-01-10 06:42:10 <gmaxwell> petertodd: and you screw up privacy in the process.
 650 2013-01-10 06:42:13 <petertodd> yes yes and yes, as I say, it's automated
 651 2013-01-10 06:42:40 <gmaxwell> And besides, if you're running all this proof crap, why do you need something to deposit coin at in the first place. :P
 652 2013-01-10 06:42:42 <petertodd> bitcoinfog and torwallet do exactly that, every coin goes into a big pot
 653 2013-01-10 06:43:03 <gmaxwell> petertodd: yea, so they can be stolen. It's pointless, you can do mixing with no trust at all.
 654 2013-01-10 06:43:14 <gmaxwell> (you author a joint transaction)
 655 2013-01-10 06:43:29 <petertodd> no, mixing is vulnerably to finney attacks and requires lots and lots of transaction to resist that
 656 2013-01-10 06:43:31 skeledrew has quit (Ping timeout: 276 seconds)
 657 2013-01-10 06:43:38 <petertodd> this requires one transaction and a service with a lot of use
 658 2013-01-10 06:43:39 <gmaxwell> ...
 659 2013-01-10 06:43:45 grau has joined
 660 2013-01-10 06:43:46 <gmaxwell> No it's not. It's fill or kill.
 661 2013-01-10 06:44:01 <kjj> I chuckle at the people that reply to MPOE-PR.  She's almost always right in the end, but she says things that people don't want to hear
 662 2013-01-10 06:44:07 nus has joined
 663 2013-01-10 06:44:15 <gmaxwell> petertodd: you have an input in your wallet, I have an input. Togeather we spend them in one transaction. Two new coins come out. Who owns which? no one knows.
 664 2013-01-10 06:44:17 <petertodd> so you're saying mixing isn't finney vulnerable?
 665 2013-01-10 06:44:18 <gmaxwell> Except us.
 666 2013-01-10 06:44:29 <gmaxwell> petertodd: it's not.
 667 2013-01-10 06:44:37 <petertodd> yes, but who's the other party? maybe that's the government collecting data to resist mixing
 668 2013-01-10 06:44:41 <petertodd> flooding the network with mix offers
 669 2013-01-10 06:44:48 theymos has joined
 670 2013-01-10 06:45:36 <gmaxwell> I contact my counterparties over tor, doesn't matter much if I'm mixing with the evil spys (lets not make the goverment the enemy they're usually not in civilized places) ... that mixing does no harm but also no good.
 671 2013-01-10 06:46:01 <gmaxwell> meanwhile your fidelity bonded place is run by the spys. "oops"
 672 2013-01-10 06:46:06 <petertodd> alright, it's blockchain.info trying to collect good tx data :)
 673 2013-01-10 06:46:11 <kjj> petertodd: say you and I both need to make a 1 BTC payment around the same time.  we both give our proposals to the mixer, the mixer mulls it over for a while, and then gives us both back a transaction to be signed.  it has 83 inputs and 83 outputs.  no rhyme or reason anywhere, but the inputs that I wanted to spend are in there, as are the outputs I wanted to spend to
 674 2013-01-10 06:46:42 <kjj> It has my stuff, I don't care about the rest.  I sign it.  if someone pulls a finney, the whole transaction is undone, not just my part
 675 2013-01-10 06:46:56 skeledrew has joined
 676 2013-01-10 06:47:00 <petertodd> right, see that is true, with centralized mixers you have a hope, although you're limited in that you really want a publicly known central mixer
 677 2013-01-10 06:47:10 <gmaxwell> 83 is a bit big. But the point remains.
 678 2013-01-10 06:47:41 <kjj> it can be decentralized.  there is no reason why the mixer you talked to can't talk to other mixers.  there is no reason why your node can't be a mixer too.
 679 2013-01-10 06:48:32 <petertodd> see, if your decentralized system does a mixing tx every x-seconds or something for everyone, that works provided honest mixing volume is high enough
 680 2013-01-10 06:48:33 <gmaxwell> petertodd: mixers have a problem that if they are very public they are vunlerable to coersion, and if they are secretive they are vulnerable to being just directly run by the evil parties and also very vulnrable to theft. You hope to make the theft unprofitable. I say, instead, lets make the theft impossible.
 681 2013-01-10 06:49:19 <gmaxwell> In both cases a badguy could do tracking either by sybiling the decenteralized mix, or by running the centeralized ones. (and running lots of them, so if you use many or choose at random you get the attacker's)
 682 2013-01-10 06:49:21 <petertodd> on the other hand I'm giving a better privacy guarantee
 683 2013-01-10 06:49:57 <gmaxwell> petertodd: better how? That you promise you're not really recording the in to out mapping?
 684 2013-01-10 06:50:06 <petertodd> especially if these bonded banks can be convinced to accept the tokens of other banks
 685 2013-01-10 06:50:11 <petertodd> yes, use chaum tokens
 686 2013-01-10 06:50:24 <petertodd> they do not know what the in-out mapping is
 687 2013-01-10 06:50:27 <gmaxwell> petertodd: then I'm trusting that two bonded banks aren't the same party.
 688 2013-01-10 06:50:45 <gmaxwell> oh you mean for providing the tokens.
 689 2013-01-10 06:51:03 <gmaxwell> Yea thats how that tor website I checked out worked. You used a blinded token to provide you output.
 690 2013-01-10 06:51:05 <petertodd> yup, you buy a blinded token, and them redeem it later
 691 2013-01-10 06:51:08 <kjj> crap, this is a good discussion.  I hate to go to sleep in the middle of it, but I've gotta
 692 2013-01-10 06:51:15 <gmaxwell> s/you/your/
 693 2013-01-10 06:51:25 <petertodd> yeah, what I'm proposing is a way to trust that tor website basically
 694 2013-01-10 06:51:31 <gmaxwell> petertodd: again, this can be done without the centeral party ever holding the funds.
 695 2013-01-10 06:51:45 <gmaxwell> I already gave you one which is far more solid and doesn't require they burn funds.
 696 2013-01-10 06:51:56 <gmaxwell> (the one they were using)
 697 2013-01-10 06:51:58 <petertodd> no it can't, I'm taking value in bitcoin, converting it to a non-bitcoin value, and then back again
 698 2013-01-10 06:52:18 <petertodd> yeah, but as I say, the finney attack on mixing is a problem
 699 2013-01-10 06:52:32 <petertodd> I'll agree it works if you can get a network-wide decentralized system to work though
 700 2013-01-10 06:52:34 <gmaxwell> You keep repeating it, but it doesn't make it true.
 701 2013-01-10 06:52:48 <gmaxwell> Why do you keep saying a finney attack is a problem?
 702 2013-01-10 06:53:03 <gmaxwell> There is only one transaction. What is there to finney attack?
 703 2013-01-10 06:53:15 <petertodd> as I say, you attack by making up enough counter parties that the transaction actually only had one party in it
 704 2013-01-10 06:53:54 <petertodd> it's easy to fool people into that situation, although you can try to detect it with looking at coin taint and stuff, but it's problematic
 705 2013-01-10 06:54:07 <petertodd> (assuming the attacker has a limited amount of coins to work with)
 706 2013-01-10 06:54:08 <gmaxwell> Sure. sybil attack not finney attack.
 707 2013-01-10 06:54:19 <petertodd> ah, do I just have my terms wrong?
 708 2013-01-10 06:54:25 <gmaxwell> Yes.
 709 2013-01-10 06:54:33 <gmaxwell> But you can't solve this, in your case the same attack just works by the attacker running the site.
 710 2013-01-10 06:54:39 <petertodd> hey, I've got a fine arts degree you know :)
 711 2013-01-10 06:54:44 <gmaxwell> or also by flooding the mix.
 712 2013-01-10 06:55:27 <gmaxwell> I don't mind if you get the terms wrong, just so long as it doesn't confuse me!
 713 2013-01-10 06:55:44 <petertodd> provided a given service has at least more than one honest user in the period between your deposit and your withdrawl your ok
 714 2013-01-10 06:55:57 <gmaxwell> but thats also the case for the trust free one.
 715 2013-01-10 06:56:44 <gmaxwell> Basically I don't see what your bonds buy of the exact same thing but implemented in a way that there is only one transaction per mix, which spends all the users coins.  Other than detalis like pratical sizes of the anonymity set.
 716 2013-01-10 06:56:46 <petertodd> right, but in the trust free one you need the honest user to be in the same round, with my system you have much more flexibility
 717 2013-01-10 06:57:04 <petertodd> of course, you can chain rounds in trust-free, but that uses a pile of txes and the like
 718 2013-01-10 06:57:47 <gmaxwell> Okay, I agree. Mine still wins, if nothing else in a worse is better sense: costs less to setup up, achieves a higher security from theft comfort factor... the cost is an ambigious reduction in the anonymity set size that only matters under some attack models.
 719 2013-01-10 06:57:55 <petertodd> and you still need to solve the sybil problem to have any assurance that the rounds you think are happening are really as much usage as you think
 720 2013-01-10 06:58:22 <gmaxwell> The same is true for your bigger system though I agree you could pratically make a bigger anonymity set and make that less of an issue.
 721 2013-01-10 06:59:01 <petertodd> Okay, I agree. Mine still wins, if nothing else in a worse is better sense: lets users quickly spend their coins while still achieving security, also gives fast non-blockchain transactions, etc.
 722 2013-01-10 06:59:27 <petertodd> (note how with a site with plenty of traffic, buying then immediately redeeming your coin *is* ok)
 723 2013-01-10 06:59:27 <gmaxwell> hah. :P
 724 2013-01-10 07:00:07 <petertodd> hey, I wouldn't want to do a 10,000BTC tx in my system, but on the other hand I can play satoshidice on my system and not bloat the blockchain
 725 2013-01-10 07:00:27 <petertodd> (er, I mean, a site with plenty of deposits actually)
 726 2013-01-10 07:00:47 <gmaxwell> What kjj wanted to do is a little modifed, where a distributed system lets you anonymusly find a mate every time you want to make a payment. So the total transaction count isn't increased at all (no mix transactions). And there would be so much mixing that even if there were a lot of sybils well? hard to rason about.
 727 2013-01-10 07:01:19 <gmaxwell> yea, perhaps we should get off mixes and talk about fast transactions and femto payments.
 728 2013-01-10 07:01:24 <gmaxwell> I'll totally grant you those systems.
 729 2013-01-10 07:01:28 <petertodd> yeah, if heavily used, IE a default feature of the bitcoin client, it'd probably be ok, and in any case it'd mix up the tx dag in general which is important too
 730 2013-01-10 07:01:39 <gmaxwell> Though I note your fidelty bond doesn't solve the site getting hacked.
 731 2013-01-10 07:01:53 <petertodd> well, I just registered trustcoin.org, and I fully intend to call it a fact/micro transaction system more than anything, privacy is just a nice bonus
 732 2013-01-10 07:02:05 <gmaxwell> I think only a modest percentage of users using this will totally bugger a lot of deanonymization attempts.
 733 2013-01-10 07:02:35 <petertodd> of course, if anything the fidelity bond makes it *more* easy to get hacked, because the terms are a nasty "do everything right or you lose your bond" in the easiest implementation
 734 2013-01-10 07:03:31 <petertodd> probably true, and of course, my bonds thing is quite capable of using the trustless mixers to do the actual transactions too
 735 2013-01-10 07:03:46 <gmaxwell> petertodd: an interesting thought would be to run the sites engine in an ibmcryptocard that attests to its software.
 736 2013-01-10 07:04:00 <gmaxwell> And the bond is only that the software did what it was supposted to do.
 737 2013-01-10 07:04:06 <gmaxwell> (e.g. what the source code said)
 738 2013-01-10 07:04:07 <petertodd> well heck, hal did a whole currency implementation that way years ago
 739 2013-01-10 07:04:13 <gmaxwell> I know he did.
 740 2013-01-10 07:04:25 <gmaxwell> I talked to him a bunch about it at the time!
 741 2013-01-10 07:04:44 <gmaxwell> He tried to talk me into writing a gui for it. :P
 742 2013-01-10 07:04:47 <petertodd> as an aside, fro that reason I really want to see wide-spead trusted computing with remote attestation, making whole currencies out of it becomes easy
 743 2013-01-10 07:04:56 <petertodd> ha, good job, I was off in art school making clocks...
 744 2013-01-10 07:05:32 <gmaxwell> well it's not a cure all. Those devices can be compromised with enough motivation, but that might be a role where your bonds can play in.
 745 2013-01-10 07:06:00 grau has quit (Remote host closed the connection)
 746 2013-01-10 07:06:29 <gmaxwell> A neat thing is that you could potentially machine verify the fidelity of the oracle, and have the bond be over that. That way if they get 0wned because their attested source code with vulnerable.. well not their fault. You could have reviewed it yourself.
 747 2013-01-10 07:06:36 <petertodd> of course, but it's valuable in itself to know that those devices are compromisable, and these systems give undenyable proof when they are
 748 2013-01-10 07:07:19 brwyatt is now known as brwyatt|Away
 749 2013-01-10 07:07:23 <petertodd> yeah, that's a very nice way to do it
 750 2013-01-10 07:07:47 <petertodd> it'd also side-step the issue of having to have a good way of publishing fraud proofs that my system has
 751 2013-01-10 07:07:55 <petertodd> that's a nasty, ugly problem
 752 2013-01-10 07:08:05 <petertodd> albeit with plenty of almost good enough solutions
 753 2013-01-10 07:08:44 deano has left ()
 754 2013-01-10 07:08:58 <gmaxwell> well, the proofs might be big though, you'd basically need to log all the I/O, and the proof is just an external replay that agrees or disagrees.
 755 2013-01-10 07:09:07 grau has joined
 756 2013-01-10 07:10:03 <petertodd> nah, it's not that bad, my post found that the proofs can be as simple as just the transactions themselves, essentially it's a stateless protocol
 757 2013-01-10 07:10:40 <gmaxwell> Intresting thinking, but ya, micropayments and fast transactions are far more interesting than mixes. I can't move things off the chain in a secure manner within the chain by defintion.
 758 2013-01-10 07:10:48 <petertodd> for instance, if the scriptPubKey of the requested output is encoded in the token itself, the proof of fraud is done by publishing the token, and the proof of not-fraud is done by checking if that tx was paid as required
 759 2013-01-10 07:11:23 <petertodd> yup, it's also a much more appealing project politically, privacy is just a side-effect
 760 2013-01-10 07:11:23 <gmaxwell> oh I see your goal would be to run a bitcoin <> chaum token gateway and nothing else.
 761 2013-01-10 07:11:41 <gmaxwell> then from the tokens you could do lots of things.
 762 2013-01-10 07:11:45 <petertodd> pretty much, although bitcoin <> chaum token *deposit* service is more accurate
 763 2013-01-10 07:11:46 <gmaxwell> and only the gateway must be provable.
 764 2013-01-10 07:11:58 <petertodd> yeah
 765 2013-01-10 07:12:10 <gmaxwell> wow, yea that absolutely should be on a cryptocard. They show up on ebay cheap from time to time. The part that must be proven will be quite small.
 766 2013-01-10 07:12:18 <petertodd> it needs to accept deposits, accept withdrawls to bitcoins, and accept chaum-to-chaum transfers
 767 2013-01-10 07:12:47 <petertodd> I was considering that, but I dislike solutions that require unusual hardware
 768 2013-01-10 07:12:54 <gmaxwell> and the fidelity bond boosts the trusted computing part to pretty darn good.
 769 2013-01-10 07:13:04 <petertodd> yeah, do them both at the same time
 770 2013-01-10 07:13:43 <petertodd> the bond then is your bond to keep the service *running*
 771 2013-01-10 07:13:48 <petertodd> performance bond really
 772 2013-01-10 07:13:49 <gmaxwell> Yea, but oohh its so much nice. I dunno if you noticed, but its actually hard to convince some people that a fidelity bond works.. and besides the fidelity bond will be costly. And the software will need to be hardened as hell due to hackers. (which your fidelity bond doesn't protect)
 773 2013-01-10 07:14:16 <petertodd> ha, you think? fuck people just don't get game theory, lol
 774 2013-01-10 07:14:25 <gmaxwell> well it's also a bond that you didn't get out an electrom microscope or a gamma ray glitch emitter and recover the cryptocards private keys.
 775 2013-01-10 07:14:31 <petertodd> well, my plan is write it in python and be careful basically
 776 2013-01-10 07:14:42 <petertodd> yup, that too
 777 2013-01-10 07:14:59 <petertodd> (I might not be the right person to be writing this software...)
 778 2013-01-10 07:15:42 <petertodd> python probably rules out a lot of trusted computing hardware actually available, the IBM bank cards were custom os's I think
 779 2013-01-10 07:15:46 <gmaxwell> My advice is that this is fine for a prototype, not a grand idea for a protoduction system. And ya, probably not. The issue is that you're inheriting an enormous amount of totally invisible behavior.
 780 2013-01-10 07:16:13 <petertodd> the revocation aspect comes with bitcoin-like concensus issues, although at least upgrading is a solution
 781 2013-01-10 07:16:19 <gmaxwell> the older ones are i486s which you can pretty easily write posix C code that runs on. the newer ones are ppc, and I dunno what the toolchain looks like.
 782 2013-01-10 07:16:25 <petertodd> guarantee you the prototype turns into the production version...
 783 2013-01-10 07:16:39 freakazoid has quit (Ping timeout: 248 seconds)
 784 2013-01-10 07:16:40 reizuki__ has quit (Ping timeout: 244 seconds)
 785 2013-01-10 07:16:42 <petertodd> posix C is a step-back in terms of secure code...
 786 2013-01-10 07:17:09 maaku has quit (Quit: maaku)
 787 2013-01-10 07:17:25 <gmaxwell> petertodd: you can compile ATS to C,  but for something like this, it really isn't. Don't be myopic about it. Python is millions of lines of C, none of which has been audited for this purpose.
 788 2013-01-10 07:17:44 <petertodd> ats?
 789 2013-01-10 07:17:49 <gmaxwell> Your three function software could be very small.
 790 2013-01-10 07:18:19 <gmaxwell> http://www.cs.bu.edu/~hwxi/ATS/ATS.html  (and example of a more secure lanaguage which can effectively target C)
 791 2013-01-10 07:18:47 <petertodd> ahh, nice
 792 2013-01-10 07:19:25 <gmaxwell> In any case, there is an easy reason the prototype wouldn't be the final production version— the bond wouldn't be enormous.
 793 2013-01-10 07:19:41 <petertodd> of course, what I can do is write the first version in python, which creates the libraries for both clients and servers, and then re-write the core functionality as a small kernel
 794 2013-01-10 07:19:50 <gmaxwell> yep!
 795 2013-01-10 07:20:12 <gmaxwell> and the small kernel runs on hardened hardware, is carefully audited, and gets a big bond on it eventually.
 796 2013-01-10 07:20:30 <petertodd> one nasty bit though is the kernel won't be so small if you want it to be able to evaluate bonds to do bank-bank transfers, but then again you can do that stuff with less-trusted oracles
 797 2013-01-10 07:21:04 <petertodd> first version runs on testnet after all :)
 798 2013-01-10 07:21:13 theymos has quit (Remote host closed the connection)
 799 2013-01-10 07:21:25 <petertodd> and actually, step one is to write the fidelity bond library and standard
 800 2013-01-10 07:21:34 <petertodd> which can be used for more than just this project anyway
 801 2013-01-10 07:22:34 gmaxwell has quit (Read error: Operation timed out)
 802 2013-01-10 07:25:35 gmaxwell has joined
 803 2013-01-10 07:25:50 <gmaxwell> crud. irc host got powercycled
 804 2013-01-10 07:25:55 <gmaxwell> what did I miss?
 805 2013-01-10 07:26:02 <gmaxwell> 23:04 < petertodd> first version runs on testnet after all :)
 806 2013-01-10 07:26:09 <petertodd> and actually, step one is to write the fidelity bond library and standard
 807 2013-01-10 07:26:12 <petertodd> which can be used for more than just this project anyway
 808 2013-01-10 07:27:32 maaku has joined
 809 2013-01-10 07:28:57 <petertodd> gmaxwell: you there?
 810 2013-01-10 07:29:01 <gmaxwell> am now.
 811 2013-01-10 07:29:10 <petertodd> and actually, step one is to write the fidelity bond library and standard
 812 2013-01-10 07:29:13 <petertodd> which can be used for more than just this project anyway
 813 2013-01-10 07:29:34 <gmaxwell> well, I'm very excited about your idea. The idea of using a simple chaum token <> bitcoin gateway that was trustable through a number of mechenisms to enable a bunch of stuff sounds very exciting to me.
 814 2013-01-10 07:30:05 <stealth222> does bluematt's pull tester not have boost_regex?
 815 2013-01-10 07:30:11 <petertodd> thanks! so am I, although I will admit timestamping is nice too, and without the horrid consquences if I screw up
 816 2013-01-10 07:30:16 <gmaxwell> And accomplishing it will take a lot of square peg round hole pressure off bitcoin but also show with bitcoin enables— because absent bitcoin it would be hard to bootstrap such a thing.
 817 2013-01-10 07:30:28 <petertodd> absolutely, as I say, satoshidice can use this
 818 2013-01-10 07:30:40 <petertodd> (although with their max bet...)
 819 2013-01-10 07:30:44 <gmaxwell> they wouldn't want to for stupid reasons...
 820 2013-01-10 07:31:03 <petertodd> no, but at least we have yet another thing to nag them about
 821 2013-01-10 07:31:42 <gmaxwell> I mean, they could use mtgox codes today. E.g. https://ragecoin.appspot.com/  (and sure, you have to trust mtgox there... but for gamblers for the values involved.... thats not the blocking factor! :P )
 822 2013-01-10 07:32:00 <petertodd> so here's a question: have you looked at opentimestamps yet? becuause I haven't had anyone look at any code I've written for years, I want to get a sense of what I'm lacking in terms of skills
 823 2013-01-10 07:32:24 <petertodd> ha, nice site
 824 2013-01-10 07:32:53 <gmaxwell> no, still burried and have had even less time than I thought. (some wasted on IRC, but I think tonights conversation was not a waste!)
 825 2013-01-10 07:33:13 <petertodd> fair enough, same thinking here
 826 2013-01-10 07:33:42 maaku has quit (Quit: maaku)
 827 2013-01-10 07:33:45 <petertodd> the one good thing about this idea, is that the core of it is about good design, not good comp-sci or math
 828 2013-01-10 07:34:03 <petertodd> (good security as part of good design too)
 829 2013-01-10 07:35:27 <petertodd> in addition starting small is practical, because the protocol can be changed later
 830 2013-01-10 07:37:42 <gmaxwell> I like that it's based on a very simple core, means that creating machine validation of the behavior is easy. (also getting it on trusted hardware would be less hard), securing it is easier, etc.
 831 2013-01-10 07:38:56 grau has quit (Remote host closed the connection)
 832 2013-01-10 07:39:17 <petertodd> it's mostly a "implementation" project, IE: implementing something whose design is relatively well understood, even if it's never been done on this scale
 833 2013-01-10 07:39:32 <petertodd> I think we've discussed already every major detail of it
 834 2013-01-10 07:39:45 <petertodd> no fancy data structures or anything
 835 2013-01-10 07:40:06 <petertodd> and the crypto can be stubbed it for real implementations later
 836 2013-01-10 07:40:10 <gmaxwell> well lots of details...  IIRC chaum's crap was patented, but I expect the patents have expired. I'd assume for this one of the ECC ones would be better (smaller tokens).
 837 2013-01-10 07:40:52 <petertodd> yeah, the patent on RSA chaum expired recently, although large tokens are something this app can live with
 838 2013-01-10 07:41:00 <stealth222> gmaxwell: sorry for interrupting the discussion but I have a quick question. I need to do some basic pattern matching in my code and basically have two options. I can use boost_regex, which allows me to do what I want in a couple lines of code but requires -lboost_regex which adds dependencies...and it seems bluematt's tester doesn't have it...or I can implement the pattern matching from scratch - which adds more
 839 2013-01-10 07:41:00 <stealth222> nonstandard code to the project. Which approach is preferable?
 840 2013-01-10 07:41:13 <petertodd> the ECC ones don't seem to be well known, IE, they don't show up in the wikipedia page
 841 2013-01-10 07:42:22 <gmaxwell> stealth222: use boost_regex for now, and lets see if gavin has an opinion, I'm not aware of any reason we wouldn't take it.. I ... assume you're not exposing it to the network.
 842 2013-01-10 07:42:41 <stealth222> no, the regexes are hardcoded for now
 843 2013-01-10 07:43:29 <stealth222> it's just internal stuff
 844 2013-01-10 07:44:07 <gmaxwell> petertodd: wikipedia is spotty at times. You can stub in the crypto for now, it's not really a part of the design, hal might actually be someone to ask for advice on this too. It might perk his fancy.
 845 2013-01-10 07:45:53 <petertodd> sure, I happen to have a co-worker with a good, if a bit rusty, background in crypto too
 846 2013-01-10 07:46:17 <petertodd> non-blinded tokens I can implement first anyway
 847 2013-01-10 07:48:29 <gmaxwell> is dealing with token denominations a solved problem?
 848 2013-01-10 07:48:59 <petertodd> heh, I was just about to ask that... yeah, I thought usually denominations were done with a set of keypairs for each one?
 849 2013-01-10 07:49:14 <petertodd> I guess with ECC you could set the denomination as an offset from the root pubkey
 850 2013-01-10 07:49:53 <petertodd> or give the user a hash of a signed denomination message, signed in a deterministic signature algorithm (although that sounds like a lot of careful auditing...)
 851 2013-01-10 07:50:01 <gmaxwell> well, it's normally seperate keys.. I wouldn't bother otherwise, but generally one problem with blinded tokens is that the values unblind them.
 852 2013-01-10 07:50:30 <petertodd> yeah, I'd rather have the option of both fixed and variable values, the latter for convenience for day-to-day use
 853 2013-01-10 07:50:46 <petertodd> and anyway, you can always simply copy someone elses value amount...
 854 2013-01-10 07:50:53 <petertodd> (if the txin's are public)
 855 2013-01-10 07:51:16 <gmaxwell> I'd assume you'd have split and merge in the system, so copying the txins aren't enough.
 856 2013-01-10 07:51:29 <gmaxwell> But I think it could be trusted to tell you the distribution of existing token sizes.
 857 2013-01-10 07:51:40 <petertodd> I mean, the deposits to the service are known because they are on the blockchain
 858 2013-01-10 07:52:12 <gmaxwell> right, but you might deposit 10 btc, get a 10 btc token, split it to 1 btc tokens, trade around them.. pull out a 1 btc token.
 859 2013-01-10 07:52:23 <gmaxwell> so even thoug 10 went in there may be no 10 tokens existing now.
 860 2013-01-10 07:53:21 <gmaxwell> in any case, way past bedtime here.. lots of fun stuff to think on.
 861 2013-01-10 07:53:21 <petertodd> ah, right, well remember it's not like it's one deposit, one token, the outside world doesn't know if a deposit was for a token, or just someone donating money, the outside world doesn't need to know if any tokens exist at all
 862 2013-01-10 07:53:40 ovidiusoft has joined
 863 2013-01-10 07:53:45 <petertodd> ha, yeah, even if chaums didn't work for some reason, the micro-tx aspect is valuable enough to do it
 864 2013-01-10 07:54:26 <gmaxwell> not just micro, instant and micro.. fun mix.
 865 2013-01-10 07:54:35 <petertodd> right, yeah
 866 2013-01-10 07:55:12 <petertodd> interestingly too, it also makes knowing the size of the bitcoin economy impossible in the future...
 867 2013-01-10 07:55:20 MC-Eeepc has quit (Quit: Leaving)
 868 2013-01-10 07:55:20 <petertodd> not that it was easy already
 869 2013-01-10 07:56:09 <petertodd> btw: any objecttions to the name TrustBits? it's got bits in the name, and it works because of trust... I don't want to call it fooCoin, because it's not a currency in of itself
 870 2013-01-10 07:56:21 <gmaxwell> well, I think it would be good of your system if part of the trusted software was some simple counters.. e.g. that gave basic money velocity numbers.
 871 2013-01-10 07:56:36 <gmaxwell> name seems fine to me.
 872 2013-01-10 07:56:37 <petertodd> yeah, the hardware trusted version can do that for sure
 873 2013-01-10 07:56:50 <petertodd> good, well trustbits.org (and trustbit.org) is registered by me now
 874 2013-01-10 07:57:05 <petertodd> the .com is taken by some domain name parking crap
 875 2013-01-10 07:57:28 EPiSKiNG- has quit (Read error: Connection reset by peer)
 876 2013-01-10 07:57:32 <gmaxwell> ttyl
 877 2013-01-10 07:57:37 <petertodd> alright, later
 878 2013-01-10 07:57:49 EPiSKiNG- has joined
 879 2013-01-10 08:02:24 EPiSKiNG- has quit (Ping timeout: 265 seconds)
 880 2013-01-10 08:02:59 Lolcust has quit (Ping timeout: 255 seconds)
 881 2013-01-10 08:03:22 Lolcust has joined
 882 2013-01-10 08:06:51 nus has quit (Quit: Leaving)
 883 2013-01-10 08:12:26 maaku has joined
 884 2013-01-10 08:12:51 nus has joined
 885 2013-01-10 08:15:14 maaku has quit (Client Quit)
 886 2013-01-10 08:24:58 Cusipzzz_ has joined
 887 2013-01-10 08:25:52 CodesInChaos has joined
 888 2013-01-10 08:28:41 BTCOxygen has quit (Ping timeout: 246 seconds)
 889 2013-01-10 08:29:46 BlackPrapor has joined
 890 2013-01-10 08:30:11 mologie_ has joined
 891 2013-01-10 08:31:37 mologie has quit (Ping timeout: 245 seconds)
 892 2013-01-10 08:31:37 mologie_ is now known as mologie
 893 2013-01-10 08:34:09 zooko has joined
 894 2013-01-10 08:44:17 tonikt has joined
 895 2013-01-10 08:48:20 jdnavarro has joined
 896 2013-01-10 08:57:33 grau has joined
 897 2013-01-10 08:58:09 Insu has joined
 898 2013-01-10 08:59:29 grau has quit (Remote host closed the connection)
 899 2013-01-10 09:23:38 grau has joined
 900 2013-01-10 09:23:49 grau has quit (Remote host closed the connection)
 901 2013-01-10 09:29:59 Insu has quit (Remote host closed the connection)
 902 2013-01-10 09:31:37 Insu has joined
 903 2013-01-10 09:32:43 t7 has joined
 904 2013-01-10 09:42:00 paybitcoin has quit (Read error: Connection reset by peer)
 905 2013-01-10 10:05:40 nus has quit (Ping timeout: 276 seconds)
 906 2013-01-10 10:08:54 mariusursache has joined
 907 2013-01-10 10:10:46 <mariusursache> anyone managed to compile bitcoind on smartos/sunos?
 908 2013-01-10 10:11:32 nus has joined
 909 2013-01-10 10:12:09 drizztbsd has joined
 910 2013-01-10 10:12:17 one_zero has quit ()
 911 2013-01-10 10:12:36 graingert_ecs has joined
 912 2013-01-10 10:13:00 graingert_ecs is now known as Guest69834
 913 2013-01-10 10:17:03 Habbie_ is now known as Habbie
 914 2013-01-10 10:21:10 larsig has joined
 915 2013-01-10 10:30:18 testnode9 has quit (Ping timeout: 265 seconds)
 916 2013-01-10 10:31:55 rdymac has joined
 917 2013-01-10 10:34:12 testnode9 has joined
 918 2013-01-10 10:37:22 BTCOxygen has joined
 919 2013-01-10 10:37:43 _kicek is now known as kicek
 920 2013-01-10 10:41:17 swappermall has quit (Read error: Connection reset by peer)
 921 2013-01-10 10:45:31 rdymac has quit (Ping timeout: 248 seconds)
 922 2013-01-10 10:46:09 kicek has quit (Quit: Leaving)
 923 2013-01-10 10:47:37 trixisowned has quit (Read error: Connection reset by peer)
 924 2013-01-10 10:49:30 doublec has joined
 925 2013-01-10 10:52:21 rdymac has joined
 926 2013-01-10 10:55:09 rdymac has quit (Read error: Connection reset by peer)
 927 2013-01-10 11:03:22 kicek has joined
 928 2013-01-10 11:13:23 JohnGalt2 has quit ()
 929 2013-01-10 11:14:23 RazielZ has joined
 930 2013-01-10 11:16:49 MrTiggr has joined
 931 2013-01-10 11:24:43 testnode9 has quit (Read error: Operation timed out)
 932 2013-01-10 11:26:16 ivan\ has quit (Ping timeout: 276 seconds)
 933 2013-01-10 11:26:27 testnode9 has joined
 934 2013-01-10 11:26:52 kicek is now known as kiceek
 935 2013-01-10 11:27:07 coderrr has quit (Ping timeout: 255 seconds)
 936 2013-01-10 11:27:31 coderrr has joined
 937 2013-01-10 11:27:34 ivan\ has joined
 938 2013-01-10 11:36:22 Garr255 has quit (Read error: Connection reset by peer)
 939 2013-01-10 11:45:10 error3477 has joined
 940 2013-01-10 11:45:25 error3477 has left ()
 941 2013-01-10 11:53:36 ircuser-6 has quit (Ping timeout: 244 seconds)
 942 2013-01-10 12:06:34 Lolcust has quit (Quit: Nap time)
 943 2013-01-10 12:10:49 Lolcust has joined
 944 2013-01-10 12:18:43 dvide has quit ()
 945 2013-01-10 12:19:19 <jaromil> jgarzik: lame pull req on picocoin for a compat.h header, plus I have some questions...
 946 2013-01-10 12:20:56 galambo has joined
 947 2013-01-10 12:21:22 galambo has left ()
 948 2013-01-10 12:29:33 Guest69834 has quit (Remote host closed the connection)
 949 2013-01-10 12:30:32 dvide has joined
 950 2013-01-10 12:31:29 TD has joined
 951 2013-01-10 12:31:40 graingert_ecs has joined
 952 2013-01-10 12:31:47 graingert_ecs has left ()
 953 2013-01-10 12:34:12 tonikt has quit (Quit: Leaving)
 954 2013-01-10 12:44:08 rdponticelli has joined
 955 2013-01-10 12:49:47 OneEyed has quit (Ping timeout: 246 seconds)
 956 2013-01-10 12:51:59 rdymac has joined
 957 2013-01-10 12:55:05 ircuser-6 has joined
 958 2013-01-10 12:59:08 reizuki__ has joined
 959 2013-01-10 13:01:27 JZavala has quit (Ping timeout: 276 seconds)
 960 2013-01-10 13:02:16 OneEyed has joined
 961 2013-01-10 13:02:49 GMP has quit (Read error: Connection reset by peer)
 962 2013-01-10 13:03:29 rdymac has quit (Quit: This computer has gone to sleep)
 963 2013-01-10 13:04:58 valparaiso has joined
 964 2013-01-10 13:07:24 jdnavarro has quit (Ping timeout: 264 seconds)
 965 2013-01-10 13:09:38 ThomasV has joined
 966 2013-01-10 13:10:38 reizuki__ has quit (Ping timeout: 240 seconds)
 967 2013-01-10 13:13:59 valparaiso has left ()
 968 2013-01-10 13:24:51 BernankeDice has joined
 969 2013-01-10 13:26:48 BernankeDice has quit (Quit: BernankeDice)
 970 2013-01-10 13:29:35 Hashdog has joined
 971 2013-01-10 13:29:56 Nachtwind has quit (Quit: ZNC - http://znc.in)
 972 2013-01-10 13:30:59 Hashdog has left ()
 973 2013-01-10 13:31:36 Nachtwind has joined
 974 2013-01-10 13:33:58 devrandom has quit (Ping timeout: 276 seconds)
 975 2013-01-10 13:35:06 devrandom has joined
 976 2013-01-10 13:38:52 jdnavarro has joined
 977 2013-01-10 13:40:44 Nachtwind has quit (Quit: ZNC - http://znc.in)
 978 2013-01-10 13:42:41 Nachtwind has joined
 979 2013-01-10 13:42:48 Nachtwind has quit (Changing host)
 980 2013-01-10 13:42:48 Nachtwind has joined
 981 2013-01-10 13:43:09 datagutt has joined
 982 2013-01-10 13:50:22 nouitfvf has quit (Ping timeout: 244 seconds)
 983 2013-01-10 13:51:01 dvide has quit ()
 984 2013-01-10 13:56:26 da2ce796 has joined
 985 2013-01-10 13:58:01 da2ce7 has quit (Ping timeout: 276 seconds)
 986 2013-01-10 14:00:36 rdymac has joined
 987 2013-01-10 14:04:40 someone42 has quit (Ping timeout: 245 seconds)
 988 2013-01-10 14:06:18 someone42 has joined
 989 2013-01-10 14:10:57 rdymac has quit (Quit: This computer has gone to sleep)
 990 2013-01-10 14:14:14 agricocb has quit (Quit: Leaving.)
 991 2013-01-10 14:31:27 pusle has joined
 992 2013-01-10 14:34:11 agricocb has joined
 993 2013-01-10 14:47:00 Lolcust has quit (Quit: Nap time)
 994 2013-01-10 14:49:06 Lolcust has joined
 995 2013-01-10 14:51:30 m0mchil has quit (Remote host closed the connection)
 996 2013-01-10 14:51:59 m0mchil has joined
 997 2013-01-10 15:03:26 error3477 has joined
 998 2013-01-10 15:07:25 maaku has joined
 999 2013-01-10 15:18:17 t7__ has joined
1000 2013-01-10 15:19:11 t7 has quit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204])
1001 2013-01-10 15:19:12 t7__ is now known as t7
1002 2013-01-10 15:19:27 t7 has quit (Client Quit)
1003 2013-01-10 15:19:30 zooko has quit (Remote host closed the connection)
1004 2013-01-10 15:28:10 error3477 has left ()
1005 2013-01-10 15:29:11 paraipan has joined
1006 2013-01-10 15:30:15 rdymac has joined
1007 2013-01-10 15:32:50 jdnavarro has quit (Remote host closed the connection)
1008 2013-01-10 15:33:57 owowo has joined
1009 2013-01-10 15:37:26 freakazoid has joined
1010 2013-01-10 15:41:10 jgarzik has quit (Read error: Operation timed out)
1011 2013-01-10 15:41:27 Hashdog has joined
1012 2013-01-10 15:41:28 jgarzik has joined
1013 2013-01-10 15:41:52 jgarzik is now known as Guest9882
1014 2013-01-10 15:43:22 Hashdog has left ()
1015 2013-01-10 15:43:36 porquilho has joined
1016 2013-01-10 15:54:09 Guest9882 has quit (Read error: Operation timed out)
1017 2013-01-10 15:55:13 maaku has quit (Quit: maaku)
1018 2013-01-10 15:57:17 <etotheipi_> are all freenode IRC channels logged by default?  or do I have to register or something?
1019 2013-01-10 15:57:34 Guest9882 has joined
1020 2013-01-10 16:00:00 <sipa> they're not
1021 2013-01-10 16:00:45 <etotheipi_> how do I setup bitcoin-armory to be logged?
1022 2013-01-10 16:00:48 <etotheipi_> or do I have to log it myself?
1023 2013-01-10 16:01:09 <sipa> yes
1024 2013-01-10 16:01:14 <etotheipi_> gah
1025 2013-01-10 16:01:15 <sipa> typical irc clients do that
1026 2013-01-10 16:01:31 testnode9 has quit (Quit: Ex-Chat)
1027 2013-01-10 16:01:41 <etotheipi_> yeah, this was more for users that wanted to search the discussion when they weren't logged in
1028 2013-01-10 16:03:41 <Luke-Jr> etotheipi_: note that publicly logged channels need to say so in the topic
1029 2013-01-10 16:03:49 MrTiggr has quit (Ping timeout: 276 seconds)
1030 2013-01-10 16:05:10 Guest9882 has quit (Read error: Operation timed out)
1031 2013-01-10 16:07:27 andytoshi has joined
1032 2013-01-10 16:08:20 mariusursache has left ()
1033 2013-01-10 16:08:34 Guest9882 has joined
1034 2013-01-10 16:14:36 theorbtwo has quit (Remote host closed the connection)
1035 2013-01-10 16:16:42 WolfAlex has joined
1036 2013-01-10 16:17:24 theorbtwo has joined
1037 2013-01-10 16:19:29 freakazoid has quit (Ping timeout: 240 seconds)
1038 2013-01-10 16:19:52 torsthaldo has joined
1039 2013-01-10 16:37:13 t7 has joined
1040 2013-01-10 16:42:11 tonikt has joined
1041 2013-01-10 16:47:18 sgornick has joined
1042 2013-01-10 16:50:51 Guest9882 has quit (Changing host)
1043 2013-01-10 16:50:51 Guest9882 has joined
1044 2013-01-10 16:50:54 Guest9882 is now known as jgarzik
1045 2013-01-10 16:54:33 GMP has joined
1046 2013-01-10 16:57:35 johzi has quit (Ping timeout: 246 seconds)
1047 2013-01-10 16:59:36 bitafterbit has joined
1048 2013-01-10 17:01:44 <jgarzik> jaromil: thanks, merged
1049 2013-01-10 17:05:20 swulf-- has joined
1050 2013-01-10 17:06:18 <stealth222> I'm building bitcoin-qt on OS X 10.8 and am getting an error when I use -mmacosx-version-min=10.5 which goes away if I do -mmacosx-version-min=10.7
1051 2013-01-10 17:07:09 <stealth222> so 1) do we need to support 10.5? 2) if so, what's the solution/workaround to this issue?
1052 2013-01-10 17:07:52 swulf--1 has quit (Ping timeout: 256 seconds)
1053 2013-01-10 17:09:21 t7 has quit (Remote host closed the connection)
1054 2013-01-10 17:10:10 maaku has joined
1055 2013-01-10 17:11:41 <stealth222> specifically, std::basic_ostream issues and QtCore/qglobal.h issues
1056 2013-01-10 17:12:29 WolfAlex_ has joined
1057 2013-01-10 17:12:44 WolfAlex has quit (Quit: No Ping reply in 180 seconds.)
1058 2013-01-10 17:21:28 B0g4r7 has quit (Ping timeout: 276 seconds)
1059 2013-01-10 17:21:36 rdymac has quit (Quit: This computer has gone to sleep)
1060 2013-01-10 17:25:07 rdymac has joined
1061 2013-01-10 17:32:34 meLon has quit (Remote host closed the connection)
1062 2013-01-10 17:33:14 toffoo has joined
1063 2013-01-10 17:39:37 kiceek has quit (Ping timeout: 256 seconds)
1064 2013-01-10 17:43:35 TD has quit (Quit: TD)
1065 2013-01-10 17:43:53 WolfAlex_ has quit (Quit: No Ping reply in 180 seconds.)
1066 2013-01-10 17:44:09 WolfAlex has joined
1067 2013-01-10 17:48:02 agricocb has quit (Remote host closed the connection)
1068 2013-01-10 17:50:36 agricocb has joined
1069 2013-01-10 17:51:14 agricocb has quit (Remote host closed the connection)
1070 2013-01-10 17:51:52 agricocb has joined
1071 2013-01-10 17:52:33 kiceek has joined
1072 2013-01-10 17:53:44 <parus> Hey, i received some funds from an ewallet into my local wallet about a month ago, but it still has no confirmations... is there anything i can do?
1073 2013-01-10 17:56:10 <BlueMatt> is there a list somewhere of which blocks on testnet3 include fun test cases i should port to pull-tester?
1074 2013-01-10 17:56:53 <andytoshi> parus, how many blocks do you have?
1075 2013-01-10 17:56:55 <stealth222> BlueMatt: can you add libboost_regex to pull-tester?
1076 2013-01-10 17:56:56 <andytoshi> ;;bc,blocks
1077 2013-01-10 17:56:57 <gribble> 211863
1078 2013-01-10 17:57:06 <BlueMatt> stealth222: you mean just install it?
1079 2013-01-10 17:57:09 <stealth222> yes
1080 2013-01-10 17:57:09 <Luke-Jr> parus: what txid?
1081 2013-01-10 17:57:18 <BlueMatt> stealth222: will do
1082 2013-01-10 17:57:22 <stealth222> thank you
1083 2013-01-10 17:57:27 <gavinandresen> stealth222: we definitely need to support osx 10.6.  We briefly stopped supporting 10.5, and we do still have 10.5 users, so we should try to continue supporting it.  I don't know what the issues are.
1084 2013-01-10 17:57:52 <stealth222> I could pastebin the compiler output if you want
1085 2013-01-10 17:58:13 <gavinandresen> stealth222: no, thanks, I'm busy with other things right now
1086 2013-01-10 17:58:27 <stealth222> who should I talk to about it, then?
1087 2013-01-10 17:58:45 <gavinandresen> stealth222: google?  stackoverflow?
1088 2013-01-10 17:58:46 <parus> Luke-Jr: bfabdb72068bbc5d77439d864ffa503d74f6656071ba0aa495caa1fa4f626b11
1089 2013-01-10 17:59:08 <stealth222> isn't there anyone on the project that's specializing in qt stuff?
1090 2013-01-10 17:59:18 <Luke-Jr> stealth222: wumpus and Diapolo mainly
1091 2013-01-10 17:59:27 <gavinandresen> but they don't develop on mac
1092 2013-01-10 17:59:34 <Luke-Jr> parus: this has over 4000 confirms
1093 2013-01-10 17:59:35 <stealth222> I mean, i could research it all myself - but someone who already encountered these issues would surely save me a great deal of time
1094 2013-01-10 18:00:01 <stealth222> but if there's nobody, I guess it's on me :)
1095 2013-01-10 18:00:31 <parus> Luke-Jr: ok, bitcoin-qt says 'ney' (means 0).
1096 2013-01-10 18:00:43 <Luke-Jr> parus: is it sync'd up?
1097 2013-01-10 18:00:53 <parus> yes, should be
1098 2013-01-10 18:01:08 <parus> i switched the wallets recently, i hope, thats not a problem
1099 2013-01-10 18:01:40 MobiusL has quit (Quit: Ex-Chat)
1100 2013-01-10 18:01:56 ThomasV has quit (Quit: Leaving)
1101 2013-01-10 18:01:59 <parus> 216035 downloaded blocks
1102 2013-01-10 18:02:10 <parus> *216025
1103 2013-01-10 18:02:20 topace has quit (Ping timeout: 246 seconds)
1104 2013-01-10 18:02:44 <stealth222> so there's nobody in the bitcoin-dev core group who is testing bitcoin-qt on OS X?
1105 2013-01-10 18:03:26 <gmaxwell> Gavin.
1106 2013-01-10 18:03:36 <stealth222> lol - but Gavin doesn't want to help :p
1107 2013-01-10 18:03:48 <Luke-Jr> stealth222: you can be that somebody :D
1108 2013-01-10 18:03:51 <gmaxwell> Well gavin uses OSX but that doesn't make him an all powerful osx ninja.
1109 2013-01-10 18:04:06 <stealth222> Luke-Jr: looks like it's gonna have to be that way :p
1110 2013-01-10 18:04:20 Doji has joined
1111 2013-01-10 18:04:30 <Luke-Jr> stealth222: Windows is in a similar situation, but we can build Windows binaries from Linux :P
1112 2013-01-10 18:04:47 JZavala has joined
1113 2013-01-10 18:05:00 error3477 has joined
1114 2013-01-10 18:05:13 error3477 has left ()
1115 2013-01-10 18:05:43 <stealth222> being able to build is not exactly the same as making sure it runs as it should
1116 2013-01-10 18:06:05 <stealth222> although it's obviously a prerequisite
1117 2013-01-10 18:06:53 <BlueMatt> does anyone remember a reason why pull-tester would be using boost1.42 instead of boost1.40 like gitian/jenkins does?
1118 2013-01-10 18:06:58 topace has joined
1119 2013-01-10 18:07:22 topace is now known as Guest71149
1120 2013-01-10 18:07:26 <BlueMatt> oh well, back to 1.40 now (with regex)
1121 2013-01-10 18:07:36 <BlueMatt> stealth222: what pull do you want re-tested?
1122 2013-01-10 18:07:47 <stealth222> 2124
1123 2013-01-10 18:08:28 Guest71149 has quit (Changing host)
1124 2013-01-10 18:08:28 Guest71149 has joined
1125 2013-01-10 18:08:39 Guest71149 is now known as topace_
1126 2013-01-10 18:09:32 <stealth222> although the qt build will almost surely fail until I update the project file to use -lboost_regex
1127 2013-01-10 18:09:48 <BlueMatt> gmaxwell: do you at least have a few guesses as to which testnet3 blocks are "interesting"
1128 2013-01-10 18:11:13 <stealth222> ok, BlueMatt - now you can retest :)
1129 2013-01-10 18:11:27 <gmaxwell> BlueMatt: the test cases at low heights, the super big ones at around 4000... I don't know what else— why?
1130 2013-01-10 18:12:13 <BlueMatt> gmaxwell: just wondered what i should throw in pull-tester (didnt you recently add something that tripped up bitcoinj, at least)
1131 2013-01-10 18:12:24 <gmaxwell> I could make an interesting map by doing this: compile bitcoin with gcov, and then after every block it syncs trigger the gcov branch collection. I could then give you a list code coverage increase by blocks.
1132 2013-01-10 18:13:00 <stealth222> BlueMatt: /usr/bin/ld: cannot find -lboost_unit_test_framework
1133 2013-01-10 18:13:07 <gmaxwell> I have to either find the last code I did that trick to or remember how to do it first though. :P
1134 2013-01-10 18:13:07 <BlueMatt> gmaxwell: if you want to put in that much effort....
1135 2013-01-10 18:13:11 <BlueMatt> stealth222: saw that, sorry, one sec
1136 2013-01-10 18:13:32 OneEyed has quit (Quit: WeeChat 0.3.9.2)
1137 2013-01-10 18:13:36 <gmaxwell> well, it's 20 minutes if I can find code I'd already done that to to copy and paste.
1138 2013-01-10 18:13:50 MobiusL has joined
1139 2013-01-10 18:13:53 <BlueMatt> gmaxwell: ahh, well ok, if you find it that'd be cool
1140 2013-01-10 18:14:07 grau has joined
1141 2013-01-10 18:17:48 rdymac has quit (Quit: This computer has gone to sleep)
1142 2013-01-10 18:17:54 TD has joined
1143 2013-01-10 18:19:15 Doji has quit (Excess Flood)
1144 2013-01-10 18:21:30 Doji has joined
1145 2013-01-10 18:26:40 <BlueMatt> stealth222: hmm...that also looks like a pull-tester issue, though i dont really have time to fix it right now
1146 2013-01-10 18:26:48 <BlueMatt> Ill try to get it fixed by the end of the day
1147 2013-01-10 18:26:59 <stealth222> BlueMatt: no problem - thanks
1148 2013-01-10 18:27:52 <BlueMatt> gmaxwell: no rush, btw, i wont get around to it till tomorrow or the weekend in any case
1149 2013-01-10 18:28:09 <BlueMatt> (assuming my comp parts dont show up before then...)
1150 2013-01-10 18:28:19 reizuki__ has joined
1151 2013-01-10 18:28:26 <etotheipi_> can someone answer a couple questions about the JSON-RPC interface?  for instance, what address is shown in listtransactions for "send" tx?  just the first TxIn address?  what about if you send a tx from account A to account A:  is that shown as two tx?
1152 2013-01-10 18:29:44 sgornick has quit (Ping timeout: 248 seconds)
1153 2013-01-10 18:32:10 <stealth222> yes
1154 2013-01-10 18:32:34 <stealth222> one is +, the other is -
1155 2013-01-10 18:32:58 owowo has quit (Ping timeout: 276 seconds)
1156 2013-01-10 18:33:23 osmosis has joined
1157 2013-01-10 18:36:31 <gavinandresen> etotheipi_: listtransactions shows the destination address for "send" tx.  If you send to multiple destinations, you'll get multiple entries, each with the same txid.
1158 2013-01-10 18:37:10 <gavinandresen> etotheipi_: and stealth222 is right, a send-to-self generates + and - entries.
1159 2013-01-10 18:37:16 <etotheipi_> gavinandresen: you'll have to excuse my ignorance... I've never used the RPC interface
1160 2013-01-10 18:37:30 grau has quit (Remote host closed the connection)
1161 2013-01-10 18:37:38 <etotheipi_> so the list doesn't have to be a perfect partition of transactions... it's not all going to add up perfectly to your current balance
1162 2013-01-10 18:37:48 <gavinandresen> etotheipi_: no problem.  Experimenting with -testnet coins is a good way of seeing what it does
1163 2013-01-10 18:38:08 <etotheipi_> for instance, you may have a multi-address output, you will have one entry for each output and the fee will be specified the same on all of them
1164 2013-01-10 18:38:18 BlackPrapor has quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
1165 2013-01-10 18:38:38 <gavinandresen> etotheipi_: yes.  If you want a perfect partition you'll have to pay attention to the txids
1166 2013-01-10 18:38:43 <etotheipi_> got it
1167 2013-01-10 18:39:00 <etotheipi_> I'm working on an Armory RPC interface and I just wanted to make sure I match the behavior
1168 2013-01-10 18:40:11 <gavinandresen> sends-to-self and hiding the "change" are the nasty bits.
1169 2013-01-10 18:40:23 JZavala has quit (Ping timeout: 245 seconds)
1170 2013-01-10 18:41:18 <etotheipi_> gavinandresen: luckily I have all that implemented pretty robustly in the GUI
1171 2013-01-10 18:41:44 <etotheipi_> but yes, I agree... it wasn't pleasant to do it
1172 2013-01-10 18:42:36 sgornick has joined
1173 2013-01-10 18:43:27 <etotheipi_> gavinandresen: actually, how does bitcoind determine the change on a sent-to-self tx?
1174 2013-01-10 18:43:48 <etotheipi_> it was "easy" in Armory because I have deterministic wallets, and just assume that the address with the higher index is the change
1175 2013-01-10 18:44:26 <gavinandresen> etotheipi_: if it isn't in the address book assigned to some account (default: ""), then it is assumed to be a change key.
1176 2013-01-10 18:44:44 meLon has joined
1177 2013-01-10 18:44:45 meLon has quit (Changing host)
1178 2013-01-10 18:44:45 meLon has joined
1179 2013-01-10 18:45:06 <gavinandresen> etotheipi_: that's one of the reasons we discourage people from copying their wallets to different machines, things get very confused as keys are used as change on one and receiving address on another
1180 2013-01-10 18:46:34 <etotheipi_> gavinandresen: understood... there is no way to know for sure
1181 2013-01-10 18:46:38 <etotheipi_> in all situations
1182 2013-01-10 18:46:53 owowo has joined
1183 2013-01-10 18:48:04 <sipa> ;;genrate 6
1184 2013-01-10 18:48:04 <gribble> The expected generation output, at 6.0 Mhps, given difficulty of 3249549.58449, is 0.00092857148972 BTC per day and 3.86904787383e-05 BTC per hour.
1185 2013-01-10 18:48:30 <BlueMatt> sipa: cpu mining on a router?
1186 2013-01-10 18:48:41 <sipa> BlueMatt: a VPS :p
1187 2013-01-10 18:48:44 <BlueMatt> ahh
1188 2013-01-10 18:49:02 <sipa> (not actually, just calculating _how_ pointless it would be)
1189 2013-01-10 18:49:19 <BlueMatt> yea, i was assuming not
1190 2013-01-10 18:50:03 * BlueMatt was really excited because he found a ton of fpgas lying around that were going unused, but then i found out there would mine at, iirc, around 7-10
1191 2013-01-10 18:51:14 johzi has joined
1192 2013-01-10 18:52:50 <gmaxwell> 7-10mh hey.. thats fun.
1193 2013-01-10 18:53:46 hahuang65 has quit (Remote host closed the connection)
1194 2013-01-10 18:56:01 <BlueMatt> no, wiki says 3.125 mhash
1195 2013-01-10 18:56:08 <BlueMatt> Digilent Nexys 2 500K
1196 2013-01-10 18:56:33 <BlueMatt> anyway
1197 2013-01-10 18:58:46 sgornick has quit (Ping timeout: 265 seconds)
1198 2013-01-10 19:03:53 TD has quit (Quit: TD)
1199 2013-01-10 19:04:18 copumpkin has quit (Ping timeout: 252 seconds)
1200 2013-01-10 19:04:53 copumpkin has joined
1201 2013-01-10 19:05:32 topace_ is now known as topace
1202 2013-01-10 19:07:32 tehace has joined
1203 2013-01-10 19:08:48 MrSambal has joined
1204 2013-01-10 19:09:11 meLon has quit (Remote host closed the connection)
1205 2013-01-10 19:13:20 sgornick has joined
1206 2013-01-10 19:13:33 meLon has joined
1207 2013-01-10 19:13:33 meLon has quit (Changing host)
1208 2013-01-10 19:13:33 meLon has joined
1209 2013-01-10 19:14:51 <jgarzik> BlueMatt, gavinandresen: JFYI, been very busy getting ready for house childbirth (any day now), so haven't touched BF-funded server slated for testnet node'ing
1210 2013-01-10 19:15:50 pusle has quit (Remote host closed the connection)
1211 2013-01-10 19:16:16 <stealth222> congrats on the growing family, jgarzik
1212 2013-01-10 19:16:34 <midnightmagic> whoah..!
1213 2013-01-10 19:17:30 <sipa> jgarzik: congrats with your succesful fork() and waitkid() :p
1214 2013-01-10 19:17:35 <stealth222> lol
1215 2013-01-10 19:17:59 <jgarzik> ;p
1216 2013-01-10 19:18:45 <owowo> what is the status of that blockchain purge thing?
1217 2013-01-10 19:20:43 daybyter has joined
1218 2013-01-10 19:21:06 <owowo> wasn't there something to be implemented to purge old transaction from the blockchain? to reduce blockchain size?
1219 2013-01-10 19:21:41 <stealth222> the entire block chain still needs to be stored. what isn't needed is an index on txids
1220 2013-01-10 19:22:04 <stealth222> at least for a full verification node
1221 2013-01-10 19:23:01 <stealth222> for a lightweight wallet, you only really need your own unspent outputs
1222 2013-01-10 19:24:36 <stealth222> but there's also a coin view - that allows you to quickly see all unspent outputs - and that structure doesn't require storing entire transactions
1223 2013-01-10 19:24:47 <stealth222> not just your own unspent outputs
1224 2013-01-10 19:25:50 D34TH has joined
1225 2013-01-10 19:28:21 <stealth222> my getrawtransaction from the master branch still can grab arbitrary transactions - but I guess that feature is going away soon...
1226 2013-01-10 19:29:01 <stealth222> I'm still very much an advocate of turning it off by default but allowing it to be turned back on
1227 2013-01-10 19:29:50 ThomasV has joined
1228 2013-01-10 19:33:13 <BlueMatt> jgarzik: yea, np...not a big deal, congrats, btw
1229 2013-01-10 19:33:32 <jgarzik> tnx
1230 2013-01-10 19:34:02 <Luke-Jr> jgarzik++
1231 2013-01-10 19:39:19 drizztbsd has quit (Remote host closed the connection)
1232 2013-01-10 19:54:23 <BlueMatt> TD's suggestion (that I kinda like) for stricter adding of matched outpoints to bloom filters: in addition to do add/dont add anything options, also have a add if matches script template option: opinions?
1233 2013-01-10 19:54:47 <BlueMatt> also: probably gonna add more template matching params to use for this: opinions on how many/which may be neccessary?
1234 2013-01-10 19:55:39 <stealth222> input outpoints, transaction amount minimum?
1235 2013-01-10 19:56:07 <BlueMatt> ?
1236 2013-01-10 19:56:18 <BlueMatt> no just script matching
1237 2013-01-10 19:56:39 <BlueMatt> the general tx matching stuff is largely done
1238 2013-01-10 19:56:44 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/1795
1239 2013-01-10 19:57:34 <sipa> BlueMatt: not sure what you're asking
1240 2013-01-10 19:58:00 <BlueMatt> currently, the option is to either add outpoints of matching outputs to the filter, or not
1241 2013-01-10 19:58:24 <BlueMatt> TD's suggestion was to add a parameter that allows you to only add outpoints if the output not only matches the filter, but also a general script template
1242 2013-01-10 19:58:25 <sipa> yes
1243 2013-01-10 19:58:33 <sipa> ah
1244 2013-01-10 19:58:34 <BlueMatt> (ie i could only match p2pubkey or some other specific type)
1245 2013-01-10 19:58:56 <BlueMatt> (well, making that general)
1246 2013-01-10 19:59:12 sgornick has quit (Ping timeout: 265 seconds)
1247 2013-01-10 19:59:56 <gmaxwell> sipa: I called that. :P
1248 2013-01-10 20:00:26 <sipa> called what?
1249 2013-01-10 20:00:29 twixed has joined
1250 2013-01-10 20:00:45 <gmaxwell> the "then we'll just want to send script templates"
1251 2013-01-10 20:00:57 <BlueMatt> gmaxwell: well...it does make sense
1252 2013-01-10 20:01:16 <BlueMatt> gmaxwell: and you know TD...wants to keep it general so that all his fancy script things would match filters
1253 2013-01-10 20:01:20 <gmaxwell> 10:22 <gmaxwell> well, no one can make use of it. Perhaps they'd _like_ to have it, but it doesn't work in the case.
1254 2013-01-10 20:01:23 <gmaxwell> 10:22 <gmaxwell> meaning they might want some other protocol where they send the peer script templates and ask the peer to do fancier than bloom matching.
1255 2013-01-10 20:01:46 <sipa> i'm not sure
1256 2013-01-10 20:01:48 <BlueMatt> gmaxwell: we already have a script matching algorithm...its just a tiny refactor in any case...
1257 2013-01-10 20:02:04 <gmaxwell> next you're gonna want a metascript language. :P
1258 2013-01-10 20:02:17 <BlueMatt> we have one....well kinda
1259 2013-01-10 20:02:21 <sipa> adding more options will certainly make it easier for clients to choose the level of automatic/manualness you want on the server
1260 2013-01-10 20:02:36 <sipa> but as soon as you enable _any_ automatic adding, you need to do local tracking anyway
1261 2013-01-10 20:03:01 <sipa> to be able to reset the server side when its FP rate becomes too much
1262 2013-01-10 20:03:02 <BlueMatt> (ofc there will be options to just BLOOM_UPDATE_ALL or BLOOM_UPDATE_NONE or probably even BLOOM_UPDATE_P2PUBKEY_ONLY)
1263 2013-01-10 20:03:19 <BlueMatt> sipa: not neccessarily
1264 2013-01-10 20:03:37 <sipa> how so?
1265 2013-01-10 20:03:56 <BlueMatt> sipa: you could just count fps and regenerate the filters using the same methods they were created with originally
1266 2013-01-10 20:04:10 <sipa> sure
1267 2013-01-10 20:04:24 <sipa> i'd call that local tracking :)
1268 2013-01-10 20:04:30 <BlueMatt> ok...
1269 2013-01-10 20:04:52 <sipa> but indeed, that's less bad than i thought
1270 2013-01-10 20:05:00 <BlueMatt> well, the other issue is if you reset the filter too often, you provide the remote node with a filter which it can intersect with the original, killing anonymity quite heavily
1271 2013-01-10 20:05:19 <BlueMatt> s/heavily/quickly/
1272 2013-01-10 20:05:20 <sipa> not necessarily
1273 2013-01-10 20:05:27 <sipa> an outpoint can only be spent once
1274 2013-01-10 20:05:30 <BlueMatt> well, true, it depends on how you do it
1275 2013-01-10 20:05:39 <sipa> you can removed outpoints you already saw spent
1276 2013-01-10 20:05:40 <BlueMatt> (if you keep the exact same filter params each time...)
1277 2013-01-10 20:06:12 <BlueMatt> ahh, well that too, but if the remote peer is just checking against your pubkeys (which you will probably have to include) then it can still intersect them
1278 2013-01-10 20:06:22 <sipa> yeah
1279 2013-01-10 20:07:06 <sipa> if we're going to add flags
1280 2013-01-10 20:07:13 <sipa> why not flags for telling what to match on
1281 2013-01-10 20:08:26 <BlueMatt> Im not sure what that adds? (aside from making filters smaller with the same fp rate, but....)
1282 2013-01-10 20:08:37 <sipa> like MATCH_TXID, MATCH_OUTPUT_SCRIPT, MATCH_OUTPOINT, MATCH_INPUT_SCRIPT, ...
1283 2013-01-10 20:09:14 <BlueMatt> why though?
1284 2013-01-10 20:09:51 <sipa> if you're not matching on output scripts at all, you probably don't want to risk colliding with a very popular output script, causing you to receive everything they receive
1285 2013-01-10 20:10:26 <BlueMatt> so set a marginally higher fp rate, which accomplishes the same goal, no?
1286 2013-01-10 20:10:51 <sipa> if the data you're matching against was uniformly distributed, yes
1287 2013-01-10 20:11:04 <sipa> but for output and input scripts, that is not the case
1288 2013-01-10 20:11:21 <BlueMatt> you never match scripts, only script objects (and never opcodes)
1289 2013-01-10 20:11:27 <sipa> yes
1290 2013-01-10 20:11:36 <sipa> some script data elements are very common. others are only used once
1291 2013-01-10 20:11:43 <BlueMatt> ahh, you mean address reuse
1292 2013-01-10 20:11:49 <sipa> yes
1293 2013-01-10 20:12:32 <etotheipi_> jgarzik: I have your bitcoin-jsonrpc python module which appears to give you authenticated access to a JSON-RPC bitcoind server
1294 2013-01-10 20:12:48 <etotheipi_> do you have a similar module for running a JSON-RPC server with authentication?
1295 2013-01-10 20:12:48 <jgarzik> etotheipi_: correct
1296 2013-01-10 20:13:09 Jezzz has joined
1297 2013-01-10 20:13:56 <jgarzik> etotheipi_: that's pool server / proxy territory, at that point.  I wrote http://yyz.us/bitcoin/poold.py but it is not really a module.
1298 2013-01-10 20:14:17 sgornick has joined
1299 2013-01-10 20:14:41 <etotheipi_> oh, I just realized that none of your stuff is twisted...?
1300 2013-01-10 20:14:57 <etotheipi_> I see like 800 ways to implement authentication on a twisted-txjsonrpc server which is what I was planning to use...
1301 2013-01-10 20:16:33 <etotheipi_> nevermind then... back to my search for good example code...
1302 2013-01-10 20:16:38 <etotheipi_> (for twisted)
1303 2013-01-10 20:16:47 <etotheipi_> thanks though
1304 2013-01-10 20:21:05 freakazoid has joined
1305 2013-01-10 20:21:15 BCB has joined
1306 2013-01-10 20:22:23 tonikt has quit (Read error: Connection reset by peer)
1307 2013-01-10 20:23:03 <jgarzik> etotheipi_: it's just an HTTP server with access to HTTP headers
1308 2013-01-10 20:23:11 <jgarzik> etotheipi_: twisted has tons of example code for that
1309 2013-01-10 20:23:22 <etotheipi_> jgarzik: the problem is, there's too much
1310 2013-01-10 20:23:26 <jgarzik> etotheipi_: plus the python built-in 'json' module
1311 2013-01-10 20:23:48 <etotheipi_> and it's frustrating, becuase I know how the protocol works, but I have to figure out how to get twisted to do it for me the right way
1312 2013-01-10 20:24:07 <etotheipi_> portals, realms, credential factories
1313 2013-01-10 20:24:33 <etotheipi_> sounds like a bad game
1314 2013-01-10 20:24:36 <Luke-Jr> etotheipi_: Twisted totally screws up Python (IMO makes it unreadable), and doesn't even support current Python versions
1315 2013-01-10 20:25:13 <Luke-Jr> etotheipi_: Eloipool is somewhat modular, but not originally designed for non-pool stuff
1316 2013-01-10 20:25:23 <BlueMatt> sipa: Im just not sure here, somehow i feel like giving away that information (which type of thing Im actually matching, and are not fps) seems to reduce anonymity somehow if not properly implemented...additionally i wanna fall back to "optimize the common case, make the rare case possible" I feel like such flags add complexity that is for no good reason
1317 2013-01-10 20:25:55 <sipa> BlueMatt: yeah, i think i agree with that
1318 2013-01-10 20:25:56 <Luke-Jr> although, thinking about it, its JSONRPCServer module would probably work well for anything else
1319 2013-01-10 20:26:39 <BlueMatt> sipa: hence a BLOOM_UPDATE_P2_PUBKEY_ONLY flag as well, but...its up for debate
1320 2013-01-10 20:27:23 <sipa> BlueMatt: but somehow i dislike flags for specific templates more than flags for stuff to match on
1321 2013-01-10 20:27:29 <sipa> BlueMatt: it's not the same featureset of coutse
1322 2013-01-10 20:28:23 <BlueMatt> sipa: not against the idea, anyway its all up for discussion
1323 2013-01-10 20:28:28 <BlueMatt> ive gotta go
1324 2013-01-10 20:28:32 <BlueMatt> Ill whip up an implementation
1325 2013-01-10 20:30:16 phma has quit (Ping timeout: 245 seconds)
1326 2013-01-10 20:31:08 reizuki__ has quit (Ping timeout: 240 seconds)
1327 2013-01-10 20:33:04 reizuki__ has joined
1328 2013-01-10 20:33:25 stealth222 has quit (Remote host closed the connection)
1329 2013-01-10 20:33:53 phma has joined
1330 2013-01-10 20:34:53 datagutt has quit (Quit: kthxbai)
1331 2013-01-10 20:35:55 <gmaxwell> Luke-Jr: what happened to your manual priority patches btw?  people asking about confirmations on specific transactions seems to be slowly increasing on IRC, and that 'boost my prio/ with captcha' thing would be good to have someday.
1332 2013-01-10 20:36:15 igetgames has quit (Read error: Connection reset by peer)
1333 2013-01-10 20:36:22 <Luke-Jr> gmaxwell: still sitting in the pullreq bin
1334 2013-01-10 20:36:39 ByteUnit has joined
1335 2013-01-10 20:37:11 <gmaxwell> Luke-Jr: did we ever figure out a way of making it work for transactions that didn't even meet the relay rules and were dropped at ingress?
1336 2013-01-10 20:37:21 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/1583
1337 2013-01-10 20:37:26 <Luke-Jr> gmaxwell: it was never brought up, AFAIK
1338 2013-01-10 20:37:55 <gmaxwell> hm.
1339 2013-01-10 20:38:01 <gmaxwell> Is that even an issue?
1340 2013-01-10 20:38:37 <Luke-Jr> gmaxwell: it could be, if you really want to do it
1341 2013-01-10 20:39:13 coderrr has quit (Changing host)
1342 2013-01-10 20:39:13 coderrr has joined
1343 2013-01-10 20:39:21 sgornick has quit (Ping timeout: 255 seconds)
1344 2013-01-10 20:39:57 <gmaxwell> ...
1345 2013-01-10 20:40:02 <gmaxwell> I urge people to vote for reduction of the maximum transaction size from 1 Mb to 100 Kbytes.
1346 2013-01-10 20:40:05 <gmaxwell> "That's one small step for Bitcoin now, one giant leap for its future"
1347 2013-01-10 20:40:20 <gmaxwell> Sergio, if you're reading this— stab stab stab.
1348 2013-01-10 20:40:27 stealth222 has joined
1349 2013-01-10 20:40:39 <sipa> ?
1350 2013-01-10 20:41:18 <gmaxwell> latest post in the AttacksWithOverlyStylizedNames (AWOSN) thread.
1351 2013-01-10 20:41:34 <gavinandresen> 100Kbyte+ transactions might be common and useful in the future.  Although not until the blocksize limit is raised, almost certainly
1352 2013-01-10 20:42:41 <gmaxwell> it's also enormous overkill. What we'd discussed before (adding up the txn size and txouts and comparing it to the blocksize) is much more effective than that suggestion, and also less likely to be restraining.
1353 2013-01-10 20:43:04 <gmaxwell> But my stabbing wasn't for the mechenism it was the unneeded call for mob support.
1354 2013-01-10 20:43:58 <gavinandresen> gmaxwell: mmm.  For 0.8, what would you think of adding the -large-memory flag and either an IsStandard or GetMinFee rule change?
1355 2013-01-10 20:44:31 <gmaxwell> I think we should IsStandard on that for sure.  What would large memory do?
1356 2013-01-10 20:44:57 <kjj> meh.  just dereference inputs after validation, and let GC keep things running
1357 2013-01-10 20:45:06 <gmaxwell> Fortunately there appears to be a _huge_ gap between reasonable behavior and something that could be used to attack.
1358 2013-01-10 20:45:12 <gavinandresen> Diapolo suggested-- gnu compiler flag to support using more than 2GB of memory on 32-bit Windoze
1359 2013-01-10 20:45:20 <sipa> i'd also change the priority mechanism to take utxo set size increase/decreased into account
1360 2013-01-10 20:46:12 <gavinandresen> sipa: I think we should roll out a GetMinFee change that takes into account ration of inputs to outputs
1361 2013-01-10 20:46:16 <gavinandresen> ratio
1362 2013-01-10 20:46:55 <gmaxwell> gavinandresen: ah, that would probably make the binary only run on cpus with PAE, e.g. it might make them not work on mc1984's atoms.
1363 2013-01-10 20:47:11 <gavinandresen> ... we just need to agree on what the formula should be.   GetMinFee rising for transactions above... oh, I dunno, 20Kbytes.
1364 2013-01-10 20:47:19 <gavinandresen> gmaxwell: really?  d'oh!
1365 2013-01-10 20:47:19 <gmaxwell> (fragmentation may force us into it in any case...)
1366 2013-01-10 20:47:28 sgornick has joined
1367 2013-01-10 20:48:07 <Luke-Jr> gavinandresen: is GetMinFee going to be added back into the mining selection then?
1368 2013-01-10 20:48:33 <gavinandresen> Luke-Jr: probably not.  Sorting by 'profit' is probably still the right thing for miners to do.
1369 2013-01-10 20:49:34 <gavinandresen> does anybody think that the "miner mines lots of blocks with 500Kbyte single transactions" is actually a probable, feasible attack?
1370 2013-01-10 20:49:57 <kjj> not really, no
1371 2013-01-10 20:49:59 <gmaxwell> sipa: propose formula, I'd proposed replacing size in prio with    max(size,2*size-txout_change)  with the 2* potentially being something different in order to equalize the scheme on typical txn..   GMF is another interesting idea.   Whatever it is I ought to make sure that it doesn't break being able to use an integer linear programming solver to make free txn.
1372 2013-01-10 20:50:46 sgornick has quit (Read error: Connection reset by peer)
1373 2013-01-10 20:50:59 rdymac has joined
1374 2013-01-10 20:51:11 <kjj> gavinandresen: the only response to this should be to fix the potential runaway in memory consumption.  free the inputs after use.
1375 2013-01-10 20:51:44 <gmaxwell> gavinandresen: In blocks it's a IBD nussance which we can 'fix' with smarter ibd rules. But loading the txouts into memory doesn't need blocks but can be fixed by isstandard rules.  I think the issue should get isstandarded and then go onto a fix-someday list.
1376 2013-01-10 20:51:58 <kjj> if we need changes to other parts, like the fee systems or whatever, we should do those on their own merits, not for this reason
1377 2013-01-10 20:53:05 <gmaxwell> er, darn me  2*size + txout_change.   e.g. txout reduction works directly against your size.
1378 2013-01-10 20:55:27 <gavinandresen> why 2*size ?
1379 2013-01-10 20:55:36 <gavinandresen> why not just size+txout_change ?
1380 2013-01-10 20:56:15 <gavinandresen> (e.g. 2-input, 2-output with standard pay-to-address-transactions for all 4 would make txout_change == 0, so exactly as we have now)
1381 2013-01-10 20:56:44 <sipa> so would gmaxwell's formula
1382 2013-01-10 20:57:05 <sipa> it would multiply all priorities by 2, but won't change anything relatively
1383 2013-01-10 20:57:09 <sipa> for such transactions
1384 2013-01-10 20:57:19 D34TH has quit (Read error: Connection reset by peer)
1385 2013-01-10 20:58:45 <gmaxwell> gavinandresen: in part because I didn't want the 'size' to be zero since implementations will divide by it, and I wanted to limit the priority boost you can get from txout reduction.
1386 2013-01-10 20:59:22 <sipa> make it size - txout_set_size_diff/2
1387 2013-01-10 20:59:26 <sipa> same thing :)
1388 2013-01-10 20:59:31 <sipa> eh, +
1389 2013-01-10 20:59:48 <gmaxwell> (If the boost isn't limited there is perhaps an incentie to make your w/ fee transactions bloat the txout set, and then get lots of boost to make free txn)
1390 2013-01-10 21:00:40 <gavinandresen> gmaxwell: good reasons.    do have bandwidth to write a pull request or a proposal?
1391 2013-01-10 21:01:37 <gmaxwell> In two weeks. :( I start a new job on monday (Well, really friday night) and will be really busy with that for a bit.
1392 2013-01-10 21:02:19 <sipa> gavinandresen: how critical do you think the optional txid index is, for 0.8?
1393 2013-01-10 21:02:37 Diapolo has joined
1394 2013-01-10 21:02:45 <sipa> (in the sense that it could be a "if you need that, don't upgrade - it will be there in 0.8.1")
1395 2013-01-10 21:03:02 <gavinandresen> sipa: I think we'll have lots of unhappy people if we don't do it.  How hard is it?
1396 2013-01-10 21:03:21 rdymac has quit (Ping timeout: 244 seconds)
1397 2013-01-10 21:03:21 <stealth222> I'd love to have that :)
1398 2013-01-10 21:03:26 <stealth222> I'll help however I can to make it happen
1399 2013-01-10 21:03:32 <Diapolo> love what?
1400 2013-01-10 21:03:39 <stealth222> to have an optional index for txid
1401 2013-01-10 21:03:53 <gmaxwell> From a reasoning about features perspective I'd rather add that whole set of features at once in 0.8.1 than only part of it in 0.8.0.  I'd be more motivated if there were a non-exploritory user of it (e.g. electrum-server or armory).
1402 2013-01-10 21:04:22 <gmaxwell> But both of those also would want index by address, and I don't think you're convinced that we should have that even as an option?
1403 2013-01-10 21:04:48 <gavinandresen> if we do index-by-txid, I think we should do index-by-address at the same time, enabled with the same option
1404 2013-01-10 21:04:54 <sipa> there's 4 useful combinations of indexes: utxo-only/fullchain and bytxid/byaddr
1405 2013-01-10 21:05:01 <gmaxwell> gavinandresen: the unhappyness is mitigated by the fact that we only added it in 0.7 and a lot of people don't know that it's there... Though— I currently maintain a 0.7 node for this purpose.
1406 2013-01-10 21:05:45 <sipa> gavinandresen: ideally, you want to be able to turn it off and on, and have it rebuilt in the background as well
1407 2013-01-10 21:05:52 <sipa> gavinandresen: and that will take testing
1408 2013-01-10 21:05:55 <kjj> there isn't a decent replacement for it though
1409 2013-01-10 21:06:26 <gavinandresen> sipa: NACK on turning it on/off.  If you do that, then you should get a long wait while it rescans every block and rebuilds it from scratch.
1410 2013-01-10 21:06:43 <stealth222> yeah, agreed, gavin
1411 2013-01-10 21:06:45 <gavinandresen> (unless it is trivial to turn it off, then turn it back on and re-scan from the block where you truned it off0
1412 2013-01-10 21:06:55 <gavinandresen> (which it probably would be)
1413 2013-01-10 21:07:01 <sipa> well, it's that part that will take time
1414 2013-01-10 21:07:03 <stealth222> well, it shouldn't be hard to remember where it stopped
1415 2013-01-10 21:07:21 <sipa> if it'd be a setting that you choose the moment the db is created, and is immutable after that, i guess it's reasonably simple
1416 2013-01-10 21:07:21 daybyter has quit (Quit: Konversation terminated!)
1417 2013-01-10 21:07:44 <Luke-Jr> does rescan really take long?
1418 2013-01-10 21:07:49 <gmaxwell> Reducing dependency on centeralized block explorers should be an explict goal for us. The reference client is not going to be the grandma client, so lets at least make sure it's a good infrastructure/power user client. Esp with blockexplorer being dead people basically have only one obvious option for doing things like checking to see how many confirmations a transaction has.
1419 2013-01-10 21:07:54 <gavinandresen> shouldn't be hard to check at startup:  if GetBoolArg(-fullindex) then start a thread to build/rebuild index from blockchain....
1420 2013-01-10 21:07:54 <Luke-Jr> maybe just require -rescan to turn it on after it was off?
1421 2013-01-10 21:07:59 <Luke-Jr> or -reindex
1422 2013-01-10 21:08:19 <sipa> -reindex will rebuild for sure
1423 2013-01-10 21:08:56 <sipa> gavinandresen: but then you have issues like what if a new block is found during that index rebuilding
1424 2013-01-10 21:09:08 <sipa> i do like the idea that the only way to change the setting is -reindex
1425 2013-01-10 21:09:09 <gmaxwell> sipa: byaddress utxo has value too.. fast imports of spendables.. but having a zillion options kinda stinks.
1426 2013-01-10 21:09:26 <sipa> gmaxwell: i know; that's one of the 4 combinations
1427 2013-01-10 21:09:30 <stealth222> you can turn off the network while it rebuilds
1428 2013-01-10 21:09:40 <sipa> stealth222: meh
1429 2013-01-10 21:09:53 <gmaxwell> yea. ACK on reindex.
1430 2013-01-10 21:09:54 D34TH has joined
1431 2013-01-10 21:10:16 <sipa> actually, there are 6 combinations
1432 2013-01-10 21:10:23 D34TH has quit (Client Quit)
1433 2013-01-10 21:10:27 <sipa> you can do a full-chain index, and a full-blocktree index
1434 2013-01-10 21:10:32 <gmaxwell> Diapolo: you around? I was surprised that there was no gui option to turn on and off listening.
1435 2013-01-10 21:10:45 <sipa> the latter would include txids from extinct side chains
1436 2013-01-10 21:10:50 <gavinandresen> fewer combinations to test is why I think if we do a full index we should index both by txid and txout.scriptPubKey
1437 2013-01-10 21:10:53 <kjj> -index-txid=off,utxo (default),full  -index-addr=off,utxo (default),full
1438 2013-01-10 21:11:02 rdymac has joined
1439 2013-01-10 21:11:27 <gavinandresen> NACK on giving people a gazillion combinations that we will never test.
1440 2013-01-10 21:11:27 <gmaxwell> sipa: I would probably have fullblocktree. The rational is that removing the side chains is actually more work, and having more options is more config confusion and QA burden for a very small reduction in index size.
1441 2013-01-10 21:11:32 <Diapolo> gmaxwell: I never finished my work on that whole proxy stuff, the last time it got to complex, which sipa didn't like that much. It's on my brains to-do-list though ^^.
1442 2013-01-10 21:11:40 <sipa> gmaxwell: agree
1443 2013-01-10 21:11:43 <stealth222> side chains are relatively small
1444 2013-01-10 21:12:02 <Luke-Jr> -poweruser=0/1
1445 2013-01-10 21:12:15 <Luke-Jr> :p
1446 2013-01-10 21:12:18 <gmaxwell> it does mean that my and your query results will not be a function of the chain, which is kinda sad.. but oh well.
1447 2013-01-10 21:12:19 rdymac has quit (Read error: Connection reset by peer)
1448 2013-01-10 21:12:45 <stealth222> well, couldn't the query ask for only txs in the main chain?
1449 2013-01-10 21:12:51 <sipa> the largest problem i have with this (especially the by-address index), is that it encourages people to use it for things where much more scalable solutions are possible too
1450 2013-01-10 21:12:59 <gmaxwell> stealth222: I suppose so, easy to filter.
1451 2013-01-10 21:13:04 BCB has left ("Leaving")
1452 2013-01-10 21:13:05 <sipa> on the other hand, i have no problem with such a feature for debugging
1453 2013-01-10 21:13:23 <Diapolo> gmaxwell: I'm not THAT rare in here btw.
1454 2013-01-10 21:13:31 <gmaxwell> Diapolo: you're pleasently quiet.
1455 2013-01-10 21:13:42 <sipa> for example, i'm sure that with a fullchain by-address index, people will use it instead of working on something like a watchonly wallet to observe balances
1456 2013-01-10 21:13:43 <gavinandresen> So...   txid would be  txid maps to listof(block hashes)   and  txout.scriptpubkey would be txout.scriptpubkey maps to listof(txids).   Leave it to the user to figure out which block hash is in the main chain
1457 2013-01-10 21:13:58 <sipa> gavinandresen: both would map to diskpos
1458 2013-01-10 21:14:01 <sipa> much smaller
1459 2013-01-10 21:14:16 <Diapolo> gmaxwell: sure you are discussing core stuff, which is no thing I can add something ^^
1460 2013-01-10 21:14:40 <gmaxwell> Diapolo: the UI is really some of our most important features, I just have nothing to really say about it.
1461 2013-01-10 21:14:50 devrandom has quit (Ping timeout: 276 seconds)
1462 2013-01-10 21:14:53 <gavinandresen> sipa: ok.  but given a tx diskpos, how do I get to the block header?
1463 2013-01-10 21:15:09 <gmaxwell> Diapolo: Well, I could make lots of suggestions for things for you to do! but thats kinda rude. :P
1464 2013-01-10 21:15:18 <sipa> gavinandresen: good one!
1465 2013-01-10 21:15:33 <sipa> blockpos + txpos, i suppose
1466 2013-01-10 21:15:42 <gmaxwell> what about txn which are in more than one block?
1467 2013-01-10 21:15:53 <sipa> gmaxwell: only the last one
1468 2013-01-10 21:16:13 <gavinandresen> index should map txid to listof(....)
1469 2013-01-10 21:16:17 <gmaxwell> okay, sounds correct.
1470 2013-01-10 21:16:22 <sipa> why?
1471 2013-01-10 21:16:34 <Diapolo> gmaxwell: you are free to suggest things :) (I don't think that is rude btw.) current thing I do is adding the possibility to call send coins via context menu on an address in your addrbook (yeah low priority but it's an open issue)
1472 2013-01-10 21:17:01 <gavinandresen> sipa: because conceptually that's correct, and i think it'll make dealing with reorgs trivial
1473 2013-01-10 21:17:24 <sipa> gavinandresen: there is no need to ever deal with reorgs - the index is not necessary for block validation, so it can do anything it wants
1474 2013-01-10 21:17:40 <sipa> the current getrawtransaction also only returns one transaction, and its height in the active chain
1475 2013-01-10 21:18:05 <Diapolo> sipa: quick question in between is 1.1GB RAM usage "normal" during IBD with bitcoin-qt and LevelDB1.7?
1476 2013-01-10 21:18:05 <sipa> gavinandresen: the most easy implementation is that when connecting a block, you write the position of its transactions to the index
1477 2013-01-10 21:18:10 <sipa> Diapolo: no
1478 2013-01-10 21:18:18 <sipa> 200-300 MB maybe
1479 2013-01-10 21:18:34 <sipa> but maybe windows doesn't deal well with fragmentation of memory
1480 2013-01-10 21:18:34 <Diapolo> ouch... perhaps there is some memory leak then
1481 2013-01-10 21:18:54 <kjj> where does getrawtransaction return the height?  mine just gives me hex
1482 2013-01-10 21:19:00 <sipa> oh, right
1483 2013-01-10 21:19:15 <sipa> it did that when getrawtransaction was still part of gettransaction
1484 2013-01-10 21:19:21 <MC1984> hm why is my bitcoin sitting at 140mbytes memory usage
1485 2013-01-10 21:19:33 <stealth222> kjj: add the verbose option
1486 2013-01-10 21:19:39 <stealth222> put a 1 at the end
1487 2013-01-10 21:19:44 <MC1984> its synced and has been open a few days idling
1488 2013-01-10 21:20:10 <Diapolo> MC1984: 0.8 test with LevelDB 1.7 on Win? sipas test version or an own build?
1489 2013-01-10 21:20:10 <gavinandresen> right... we don't have a way to go from arbitrary txid to "which block was this transaction in" ...
1490 2013-01-10 21:20:26 <kjj> ahh.  nifty
1491 2013-01-10 21:20:30 <gavinandresen> ... so storing just one diskpos in the index should be fine
1492 2013-01-10 21:20:34 <MC1984> 0.7.1-322-g9dbcccf-beta
1493 2013-01-10 21:20:47 <MC1984> well it been serving the chain over LAN to another machine
1494 2013-01-10 21:20:51 <sipa> gavinandresen: we do, it seems
1495 2013-01-10 21:21:04 <gavinandresen> getrawtransaction DOES return height?
1496 2013-01-10 21:21:24 <Diapolo> MC1984: that version string doesn't tell me the answer to my question ^^ 0.7.99 should be it, when it was based on current master, no?
1497 2013-01-10 21:21:31 <stealth222> no, I don't think it does, gavin
1498 2013-01-10 21:21:32 <kjj> gavinandresen: yes, when using the verbose flag 1
1499 2013-01-10 21:21:40 <stealth222> hmm
1500 2013-01-10 21:21:47 * gavinandresen goes to look at the code
1501 2013-01-10 21:21:47 <sipa> gavinandresen: we do return number of confirmations
1502 2013-01-10 21:21:48 <MC1984> its the latest one from sipas builds page
1503 2013-01-10 21:21:49 <Diapolo> MC1984: so no other connections to nodes, just one via LAN?
1504 2013-01-10 21:21:51 <stealth222> oh, right
1505 2013-01-10 21:21:55 <kjj>  bitcoind getrawtransaction "45bdb818c6c48cefbe0646269519f3529a9011caac325c5a1e7787429a91116e" 1
1506 2013-01-10 21:21:58 <kjj> "confirmations" : 184707,
1507 2013-01-10 21:21:58 andytoshi has quit (Ping timeout: 276 seconds)
1508 2013-01-10 21:22:14 <stealth222> yes, it does give height
1509 2013-01-10 21:22:16 <sipa> gavinandresen: GetTransaction returns the hash of the block it is found in, TxToJSON uses this to compute confirmations
1510 2013-01-10 21:22:19 <MC1984> it has 8 normal connections + the 1 lan connection
1511 2013-01-10 21:22:29 <gavinandresen> ah, right....
1512 2013-01-10 21:22:34 <Diapolo> MC1984: which OS?
1513 2013-01-10 21:22:38 <sipa> gavinandresen: anyway, that still doesn't mean we need to returns multiple blocks
1514 2013-01-10 21:22:42 <MC1984> xp
1515 2013-01-10 21:23:05 <sipa> because at most that will be one with confirmations, and zero or more without confirmations (in side chains)
1516 2013-01-10 21:23:33 <kjj> forks are not limited to single blocks
1517 2013-01-10 21:23:42 <sipa> kjj: sure, so?
1518 2013-01-10 21:24:13 <Diapolo> MC1984: was that the turbo build with leveldb1.7? perhaps I have a problem with my own build then... could also be
1519 2013-01-10 21:24:37 <MC1984> ah it still actively serving the chain to the LAN node (the intel atom cox)
1520 2013-01-10 21:24:43 <gavinandresen> ok, we should pop the stack to my original question:  sipa: how hard? if we're going to wait for bloom filters to get done, then we might have time to do it for 0.8?
1521 2013-01-10 21:25:34 <MC1984> http://bitcoin.sipa.be/builds/pre-0.8/ the latest build from there
1522 2013-01-10 21:25:35 <kjj> sipa: it isn't very hard to imagine a situation where a transaction made it into two valid blocks at a fork point, each with one block on top, waiting for resolution.  which one is the "real" one then?
1523 2013-01-10 21:25:49 <gavinandresen> kjj: whichever one your client saw first.
1524 2013-01-10 21:25:55 <sipa> kjj: the active chain
1525 2013-01-10 21:27:02 <kjj> right, but that's totally arbitrary.
1526 2013-01-10 21:27:32 <gmaxwell> kjj: it's not, it's important for convergence, and it's also a maximum likelyhood decision.
1527 2013-01-10 21:28:00 <gmaxwell> (unless you know, e.g. that one is likely to get rejected by some nodes, but then you ought to be rejecting it yourself)
1528 2013-01-10 21:28:12 <sipa> kjj: in almost every case where you're looking up a transaction, if it at least occurs in the active chain, that's the one you're interested in
1529 2013-01-10 21:28:18 tehace has quit (Quit: Leaving)
1530 2013-01-10 21:28:23 <MC1984> i dont understand the dfference between his leveldb17 and pre 0.8 directories :/
1531 2013-01-10 21:28:24 <Diapolo> sipa: is build_config.mk is generated when calling TARGET_OS=OS_WINDOWS_CROSSCOMPILE make libleveldb.a libmemenv.a?
1532 2013-01-10 21:28:38 <sipa> Diapolo: it should be
1533 2013-01-10 21:28:58 <gmaxwell> Though I note that we probably ought to be distinguishing height and confirmations in the RPC/UI a bit more.
1534 2013-01-10 21:29:16 <Diapolo> sipa: I'm asking because mine is different to the one you have in your leveldb17 branch... after calling make
1535 2013-01-10 21:29:30 <sipa> Diapolo: ?
1536 2013-01-10 21:29:38 <gmaxwell> A transaction at CUR_HEIGHT where we've happened to hear about a fork at the same height which doesn't include that transaction should properly be shown as confirmations: 0 not 1, even if the active chain has the transaction.
1537 2013-01-10 21:30:05 <gmaxwell> (because if we know about a fork the confirmation is not persuasive)
1538 2013-01-10 21:30:11 <Diapolo> sipa: these are the flags that your build_confik.mk doesn't contain
1539 2013-01-10 21:30:11 <Diapolo> PLATFORM_CCFLAGS= -D__USE_MINGW_ANSI_STDIO=1 / PLATFORM_CXXFLAGS= -D__USE_MINGW_ANSI_STDIO=1 and PLATFORM_SHARED_CFLAGS=-fPIC
1540 2013-01-10 21:30:32 <sipa> Diapolo: "my build_config.ml" ?
1541 2013-01-10 21:30:44 <sipa> there should be no such file in the repository
1542 2013-01-10 21:30:48 <stealth222> in an implementation I did of this, I used what I call the maxcladeblock
1543 2013-01-10 21:31:18 <stealth222> the maxcladeblock is the block that is the parent of all the current longest chains (if there's more than one)
1544 2013-01-10 21:31:35 D34TH has joined
1545 2013-01-10 21:31:45 <sipa> Diapolo: where do you find such a file?
1546 2013-01-10 21:32:08 <Diapolo> I fetched your branch sipa/leveldb17 and I have a bitcoin\src\leveldb\build_detect_platform
1547 2013-01-10 21:32:28 <sipa> yes
1548 2013-01-10 21:32:52 <Diapolo> sorry, I meant bitcoin\src\leveldb\build_config.mk
1549 2013-01-10 21:33:03 <sipa> there is no such file in my repository
1550 2013-01-10 21:33:07 <gmaxwell> stealth222: I think the ideal is something like the minimum confirmation count on all known chaings within— say— 6 blocks of the current active chain, subject to additional network health checks.  But I'm not offering to implement that, as it sonds messy.
1551 2013-01-10 21:33:09 <Diapolo> did I create that by mistake perhaps ^^ wow
1552 2013-01-10 21:33:23 <Diapolo> because bitcoin is not my build dir ^^
1553 2013-01-10 21:33:38 <sipa> Diapolo: https://github.com/sipa/bitcoin/tree/leveldb17/src/leveldb
1554 2013-01-10 21:33:47 <Diapolo> sipa: my fault, you are right...
1555 2013-01-10 21:34:20 <Diapolo> sipa: I was seeking the problem why my build is consuming so much more RAM than MC1984's build (your latest test-build)
1556 2013-01-10 21:36:26 <stealth222> FWIW this is how I've done it in the past: http://pastebin.com/Wmn81DVi
1557 2013-01-10 21:37:57 <MC1984> i thought 140mb was high :/
1558 2013-01-10 21:38:02 <MC1984> its usually 30mb or so
1559 2013-01-10 21:38:27 <gmaxwell> MC1984: what sizes are you talking abot?
1560 2013-01-10 21:38:29 <Diapolo> MC1984: do you allow incoming connections?
1561 2013-01-10 21:38:36 <MC1984> memory usage
1562 2013-01-10 21:38:39 <Diapolo> and what is your complete command line?
1563 2013-01-10 21:38:45 [\\\] has quit (Ping timeout: 256 seconds)
1564 2013-01-10 21:38:46 <gmaxwell> 30mb ? really thats sounds quite low!
1565 2013-01-10 21:39:34 <MC1984> oh the testnet is running on another machine and its 63mb
1566 2013-01-10 21:39:52 <stealth222> the main chain always goes through all the blocks in the chain that have a unique height
1567 2013-01-10 21:40:16 devrandom has joined
1568 2013-01-10 21:40:29 <kjj> my two nodes that I can see from here are using 240 MB and 400 MB
1569 2013-01-10 21:40:29 <stealth222> but to use this method it is necessary to keep a count of how many blocks are at a particular height
1570 2013-01-10 21:40:32 [\\\] has joined
1571 2013-01-10 21:40:35 <gmaxwell> sure, testnet I expct it to be low.
1572 2013-01-10 21:40:59 <MC1984> ok false alarm
1573 2013-01-10 21:41:19 <MC1984> i always thought it was about 30mb before for some reason
1574 2013-01-10 21:41:44 <Diapolo> MC1984: can you post your command line and tell me if you forward port 8333 to your client?
1575 2013-01-10 21:42:19 <kjj> a mining (p2pool) node with 8 outgoing, 0 incoming:  256 MB
1576 2013-01-10 21:42:29 <Diapolo> sipa: does your last build contain -fstack-protector-all or did you remove it because of that dependecy?
1577 2013-01-10 21:42:59 <MC1984> logtimestamps=1
1578 2013-01-10 21:42:59 <MC1984> benchmark=1
1579 2013-01-10 21:43:02 <MC1984> thats it
1580 2013-01-10 21:43:11 <MC1984> no incomming onnections, apart from the lan node
1581 2013-01-10 21:43:17 <MC1984> no port forward
1582 2013-01-10 21:43:43 <gmaxwell> Diapolo: someone should go nag mingw people to figure how how to make the SSP dependency static.
1583 2013-01-10 21:43:44 <sipa> Diapolo: i didn't remove it
1584 2013-01-10 21:43:57 <Diapolo> MC1984: I guess memory usage is lower, when there are only 8 connections in comparison to 23 I had... but that should make it that much worse for me ^^
1585 2013-01-10 21:44:21 <MC1984> ill forward and see what happens
1586 2013-01-10 21:44:26 andytoshi has joined
1587 2013-01-10 21:44:30 <Diapolo> gmaxwell: I googled the whole damn web for half an hour and couldn't find any hint about that...
1588 2013-01-10 21:44:42 Jezzz has quit (Quit: o/)
1589 2013-01-10 21:46:23 <MC1984> i think i unforwarded it after blockchain.info picked up my ip on a txn and i got creeped out :/
1590 2013-01-10 21:46:35 <gmaxwell> Diapolo: Yea, I went through that like 6 months ago. I tried to file a bug in fedora (which has a pretty active mingw team) and got blown off.  I think I failed to communicate what I wanted. But what I wanted was even more obscure than what we want.
1591 2013-01-10 21:46:38 <Diapolo> sipa: if you did not remove it how can MC1984 run that executable without libspp-0.dll?
1592 2013-01-10 21:47:03 <MC1984> lol i had to copy that dll into every bitcoin directory i have actually
1593 2013-01-10 21:47:17 <Diapolo> MC1984: thanks for clarification ^^
1594 2013-01-10 21:47:40 <Diapolo> gmaxwell: why not bundle it with the Windows builds until we have a static solution?
1595 2013-01-10 21:48:21 <sipa> 4i was hoping we would not need to get into dealing with the windows dll hell :(
1596 2013-01-10 21:48:31 <gmaxwell> Diapolo: sounds fine to me.. .though before we do that, it might be helpful to actually verify that it works. (you can probably find some ssp example code on the internet, if not I can help you write a test).
1597 2013-01-10 21:48:52 <stealth222> wait until we start supporting real plugins, sipa :p
1598 2013-01-10 21:49:01 <Diapolo> char SPP_buffer[1024];
1599 2013-01-10 21:49:01 <Diapolo> SPP_buffer[1025]=0xff;
1600 2013-01-10 21:49:01 <Diapolo> printf("%s", SPP_buffer);
1601 2013-01-10 21:49:05 <Diapolo> that triggers it :)
1602 2013-01-10 21:49:16 <gmaxwell> stealth222: process separation forever.
1603 2013-01-10 21:49:22 <gmaxwell> Diapolo: oh, you've tested already? fantastic.
1604 2013-01-10 21:50:02 <Diapolo> I did that in the beginning of that pull together with wumpus :).
1605 2013-01-10 21:51:51 <Diapolo> sipa: in this case I would say because it's a great security thing we should consider it
1606 2013-01-10 21:52:10 <sipa> Diapolo: patches welcome :)
1607 2013-01-10 21:52:12 <Diapolo> Tor also bundles it afaik
1608 2013-01-10 21:52:33 <gmaxwell> I _thought_ that if the binary was fully static it did manage to link it. Maybe I'm remembering it wrong.
1609 2013-01-10 21:52:51 <Diapolo> sipa: well I dunno where in Gitian that file resides or how we get it ^^ ... I have it as part of my MinGW installation
1610 2013-01-10 21:53:51 <gmaxwell> (What I was trying to achieve months ago was to build a _library_ with it enabled, and then have callers of the library automatically load the ssp dll instead of failing to link at runtime... and I gave up on this and stopped building the library with ssp)
1611 2013-01-10 21:53:55 _dr has quit (Read error: Operation timed out)
1612 2013-01-10 21:54:02 _dr has joined
1613 2013-01-10 21:54:22 <sipa> Diapolo: neither do i
1614 2013-01-10 21:54:43 <gmaxwell> the toolchain handles it with libgcc just fine... which is basically the same deal.
1615 2013-01-10 21:54:48 <Diapolo> sipa: I thought it is part of the used compiler...
1616 2013-01-10 21:55:22 <sipa> Diapolo: bitcoin/share/setup.nsi is the config file for the nsi package
1617 2013-01-10 21:56:30 <sipa> no idea how that works, or who wrote it
1618 2013-01-10 21:56:43 toffoo has quit ()
1619 2013-01-10 21:56:52 <sipa> or how to add a dll to it
1620 2013-01-10 21:56:55 <Diapolo> yeah for the Win installer package, but if we want to bundle that dll, we just need to add it to that package  and to our zip file for Win.
1621 2013-01-10 21:57:14 <Diapolo> question was more like where do we get that file ^^
1622 2013-01-10 21:57:32 <gmaxwell> Diapolo: copy it out of the mingw install when building.
1623 2013-01-10 21:58:02 <sipa> Diapolo: we have that file of course, during building
1624 2013-01-10 21:58:07 <sipa> it just needs to end up in the package
1625 2013-01-10 21:58:13 <Diapolo> sipa: that was what I was talking about :)
1626 2013-01-10 21:58:16 <sipa> it's part of the compiler
1627 2013-01-10 21:58:19 <Diapolo> yeah
1628 2013-01-10 21:58:27 <Diapolo> inside Gitian I think
1629 2013-01-10 21:58:31 <Diapolo> right?
1630 2013-01-10 21:58:54 <sipa> eh, yes?
1631 2013-01-10 21:59:11 <sipa> the package is built inside gitian, so that holds the entire build environment
1632 2013-01-10 21:59:43 <MC1984> bitcoin only uses tcp right
1633 2013-01-10 21:59:47 <sipa> yes
1634 2013-01-10 21:59:55 <sipa> well, DNS lookups are UDP :p
1635 2013-01-10 22:00:07 <Diapolo> sipa: so we would "just" need to integrete that dll into the root of our package and perhaps the daemon dir...
1636 2013-01-10 22:00:38 <sipa> Diapolo: i'm sure NSI knows how to install dll's The Right Way
1637 2013-01-10 22:00:47 <gmaxwell> Are those mingw builds compiled with -static?
1638 2013-01-10 22:01:13 <gmaxwell> If so, changing where -static is specified may trigger it to actually statically link it.
1639 2013-01-10 22:01:24 <Diapolo> windows looks into the root of your application, so that would be easiest
1640 2013-01-10 22:01:30 <gmaxwell> Also, if we're going the SSP route, QT and boost should be built with that flag too.
1641 2013-01-10 22:02:18 <Diapolo> all libs would need to be build with it yeah
1642 2013-01-10 22:02:31 <sipa> i can't find any -static in bitcoin-qt.pro
1643 2013-01-10 22:02:41 <Diapolo> QMAKE_LFLAGS *= -static -fstack-protector-all seems to at least build...
1644 2013-01-10 22:02:43 Hashdog has joined
1645 2013-01-10 22:03:31 <Diapolo> and it seems the dependency is gone...
1646 2013-01-10 22:03:38 <sipa> :o
1647 2013-01-10 22:03:56 <Diapolo> wait I need to verify this...
1648 2013-01-10 22:04:01 <gmaxwell> I don't see any reason that our windows builds shouldn't be -static. It's not like there are going to be useful system dlls we shold use instead.
1649 2013-01-10 22:06:07 <gmaxwell> If we're on newer mingw we should also be -flto -O3 --param inline-unit-growth=5
1650 2013-01-10 22:06:10 rdponticelli has quit (Ping timeout: 276 seconds)
1651 2013-01-10 22:06:14 <Diapolo> gmaxwell: I can't believe it was that easy, there has to be a drawback ^^
1652 2013-01-10 22:06:38 <stealth222> larger binary footprint?
1653 2013-01-10 22:06:39 grau has joined
1654 2013-01-10 22:06:47 <gmaxwell> Diapolo: yes, you end up with two copies of boost in our install.
1655 2013-01-10 22:06:58 <gmaxwell> But then again going -flto will likely recover all that size. :P
1656 2013-01-10 22:07:11 <sipa> last i tried -flto it gave a weirdo error
1657 2013-01-10 22:07:28 <Diapolo> gmaxwell: I was still talking about that libssp-0.dll dependency ^^
1658 2013-01-10 22:07:30 Davincij15 has joined
1659 2013-01-10 22:07:33 <gmaxwell> you need to give it to both the compiler and linker.
1660 2013-01-10 22:07:35 <gmaxwell> Diapolo: I know.
1661 2013-01-10 22:07:50 WolfAlex has quit (Ping timeout: 276 seconds)
1662 2013-01-10 22:08:03 <gmaxwell> but I'm saying that -static will make a binary which uses no dlls at all.. everything ends up internal, so bitcoind and bitcoin-qt will duplicate boost and openssl.
1663 2013-01-10 22:08:10 <sipa> gmaxwell: i know how to use -flto, for my local builds i always use it
1664 2013-01-10 22:08:19 <sipa> gmaxwell: but in mingw it failed in strange way
1665 2013-01-10 22:08:30 <gmaxwell> was that mingw64 or?
1666 2013-01-10 22:08:38 <sipa> mingw-w64, yes
1667 2013-01-10 22:08:42 <sipa> 4.7.2 iirc
1668 2013-01-10 22:08:45 <gmaxwell> bummer.
1669 2013-01-10 22:09:02 <sipa> it should work, though
1670 2013-01-10 22:09:14 <sipa> so perhaps with a bit of reordering/playing with flags it can work
1671 2013-01-10 22:09:28 <Diapolo> seems that small -static also removed the dependecies on all other MinGW dlls...
1672 2013-01-10 22:09:43 <grau> you guys sont think its  bit antiquated to deal with compile optioms ?
1673 2013-01-10 22:09:56 <grau> *dont
1674 2013-01-10 22:10:00 <Diapolo> grau: why? how do you do it?
1675 2013-01-10 22:10:00 Doji has quit (Ping timeout: 248 seconds)
1676 2013-01-10 22:10:26 <sipa> grau: well, unfortunately we need binaries to distribute...
1677 2013-01-10 22:10:31 <grau> I mean I compile java on my laptop and run binary on the server
1678 2013-01-10 22:10:38 <gmaxwell> sipa: at least for us it doesn't seem to make a big performance difference (which is surprising, but hey)
1679 2013-01-10 22:11:05 <sipa> grau: sure, using a platform like java helps for that
1680 2013-01-10 22:11:13 <sipa> grau: but it also has drawbacks
1681 2013-01-10 22:11:24 <gmaxwell> grau: I don't see what you're saying.
1682 2013-01-10 22:11:24 <grau> yes, and that should be leveraged
1683 2013-01-10 22:11:32 testnode9 has joined
1684 2013-01-10 22:11:38 testnode9 has quit (Remote host closed the connection)
1685 2013-01-10 22:11:43 <sipa> let's not get into a language flamewar here :)
1686 2013-01-10 22:11:48 <Diapolo> I hate Java ^^
1687 2013-01-10 22:11:51 <grau> sorry
1688 2013-01-10 22:11:53 <gmaxwell> We compile bitcoin on a determinstic build enviroment and get binaries for all our supported platforms.
1689 2013-01-10 22:12:04 <gmaxwell> oh this was just a weird language flame? nevermind!
1690 2013-01-10 22:12:20 <grau> I was just amused, the kind of problems you have is something I forgot a decade go
1691 2013-01-10 22:12:23 <grau> ago
1692 2013-01-10 22:12:37 <gmaxwell> grau: <parting retort> lemme know when you get within a factor of 10 of bitcoind's chain validation speed </parting retort>
1693 2013-01-10 22:12:52 <grau> I wont have that
1694 2013-01-10 22:12:57 <stealth222> some of us still like to build efficient code and have very granular control over things like memory management and native datatypes, grau :p
1695 2013-01-10 22:13:04 <Diapolo> gmaxwell: the only thing I don't get is why duplication of OpenSSL / boost?
1696 2013-01-10 22:13:11 <grau> but that is not what decides on adoption
1697 2013-01-10 22:13:22 <gmaxwell> Diapolo: because both bitcoind and bitcoin-qt will each have an internal copy of them.
1698 2013-01-10 22:13:25 <helo> chain validation speed is pretty critical
1699 2013-01-10 22:13:48 <gmaxwell> and ... details us programmers work out about the compile procedure will? :P
1700 2013-01-10 22:14:13 <helo> with a distributed system like bitcoin, we need as many people running full copies of the blockchain as we can get, so we need it to be as efficient as possible.
1701 2013-01-10 22:14:29 <helo> as painless as possible
1702 2013-01-10 22:14:45 <Diapolo> gmaxwell: ahhh of course I only ever think of bitcoin-qt :D
1703 2013-01-10 22:15:05 <grau> your efficiency is pointless in absence of business functions
1704 2013-01-10 22:15:06 <Diapolo> bitcoind ^^
1705 2013-01-10 22:15:07 <stealth222> Diapolo: I almost never think of bitcoin-qt - today was an exception :)
1706 2013-01-10 22:15:22 <Diapolo> hey I'm "that" GUI guy you know :D
1707 2013-01-10 22:15:31 <stealth222> Diapolo: but it looks like I'll be dealing with bitcoin-qt a lot more from now on
1708 2013-01-10 22:15:40 swulf--1 has joined
1709 2013-01-10 22:15:47 <helo> there are alternative implementations using most popular languages
1710 2013-01-10 22:16:09 <Diapolo> stealth222: that would be a good thing :) that part needs more love
1711 2013-01-10 22:16:58 <MC1984> best not be any crazeee zero days now that ive opened my port
1712 2013-01-10 22:17:40 <Diapolo> you can always enhance windows security for apps with EMET 3.0 add bitcoin-qt.exe :)
1713 2013-01-10 22:17:44 toffoo has joined
1714 2013-01-10 22:17:51 swulf-- has quit (Ping timeout: 256 seconds)
1715 2013-01-10 22:18:17 <stealth222> I'd actually really like to see a solid verification/relay daemon that builds across many platforms - and a separate GUI process that communicates with it
1716 2013-01-10 22:18:54 <sipa> stealth222: yeah
1717 2013-01-10 22:19:04 <grau> stealth222 : youl get that with bitsofproof
1718 2013-01-10 22:19:29 <Diapolo> sipa: that -static switch also enabled me to use win32:QMAKE_LFLAGS *= -static-libgcc -static-libstdc++ which crashed before... you remember?
1719 2013-01-10 22:20:09 <Diapolo> stealth222: I like that all in one feeling, but I'm not the one who decides it
1720 2013-01-10 22:20:12 <gavinandresen> ... easy when you know how.....
1721 2013-01-10 22:20:32 <stealth222> Diapolo: from the enduser's perspective, it could still be all-in-one
1722 2013-01-10 22:20:47 <sipa> grau: hmm, i thought you focussed more on featureful services rather than a fast/compact relay/verification system
1723 2013-01-10 22:20:50 <helo> is it unreasonable to think 0.9 may split the gui off?
1724 2013-01-10 22:21:02 <sipa> grau: which obviously doesn't mean it can't function as that
1725 2013-01-10 22:21:08 <Diapolo> stealth222: worst thing about usability is if you need to fiddle around with more than 2 application to get a thing to work IMO
1726 2013-01-10 22:21:17 <grau> sipa: I split the core functions from all the rest
1727 2013-01-10 22:21:27 andytosh1 has joined
1728 2013-01-10 22:21:35 <helo> grau: the reference client does too
1729 2013-01-10 22:21:46 <sipa> grau: i know that - your modularity it nice, but that doesn't mean anything for someone who wants to run it; it only makes development easier
1730 2013-01-10 22:22:25 <helo> maybe not from "all the rest", but from the GUI at least
1731 2013-01-10 22:22:33 <stealth222> Diapolo: the daemon would be installed as a service - tight integration with OS would be nice here (so that the user can configure options, such as whether to always run in the background or only when the GUI is launched)
1732 2013-01-10 22:22:35 <grau> sipa: You are right mine is not for end user, but is easier to build on
1733 2013-01-10 22:23:30 <stealth222> the GUI would always look for a running agent - if none is found, it tries to launch it.
1734 2013-01-10 22:23:34 <sipa> ;;later tell BlueMatt do you have any idea why our windows builds don't use -static ?
1735 2013-01-10 22:23:34 <gribble> The operation succeeded.
1736 2013-01-10 22:23:37 <grau> helo: not only gui but it separates e.g. mining or validated transaction feed or chain events from the rest
1737 2013-01-10 22:24:22 andytoshi has quit (Ping timeout: 276 seconds)
1738 2013-01-10 22:24:55 <stealth222> the CLI in bitcoind actually works more or less exactly like this
1739 2013-01-10 22:25:43 <stealth222> all that's needed to fully split off the GUI is callbacks
1740 2013-01-10 22:25:45 <Diapolo> gmaxwell: why didn't you suggest that -static in front of -fstack-protector-all before? I'm still exited
1741 2013-01-10 22:25:54 Hashdog has left ("PONG :niven.freenode.net")
1742 2013-01-10 22:26:18 <Diapolo> stealth222: I don't think we would love to build a Windows service ^^ or are you a skilled win32 coder?
1743 2013-01-10 22:26:33 <gmaxwell> Diapolo: because I thought we already had it, and it wasn't enough for to fix it the last time I ran into this and I didn't remember if it was enough for our case.. though if you scroll up I did recommend it earlier in the discussion too.
1744 2013-01-10 22:26:58 <stealth222> I've done it way back when, Diapolo - but I haven't really touched windows stuff in a while
1745 2013-01-10 22:27:06 <Diapolo> gmaxwell: I wasn't aware that it would fit into THAT position ^^
1746 2013-01-10 22:27:32 <stealth222> Diapolo: it isn't too extremely difficult to write a wrapper to turn it into a service
1747 2013-01-10 22:28:31 <Diapolo> stealth222: I really have no clue about Win services programming, but I know it's a tough task though
1748 2013-01-10 22:29:08 <MC1984> Diapolo that splash screen i was talking about
1749 2013-01-10 22:29:12 <stealth222> http://msdn.microsoft.com/en-us/library/windows/desktop/ms681921(v=vs.85).aspx
1750 2013-01-10 22:29:33 <MC1984> it seems to be blanks/not drawn properly when the process is hanged scanning the chain or whatever
1751 2013-01-10 22:29:48 <stealth222> it's mostly a matter of digging through some API documentation
1752 2013-01-10 22:30:27 grau has quit (Remote host closed the connection)
1753 2013-01-10 22:30:51 <stealth222> I used to specialize in win32 stuff like over a decade ago - but as I said, haven't really touched it in a while
1754 2013-01-10 22:32:29 <stealth222> Diapolo: granted, it isn't completely trivial - but I'm willing to look into it and help out
1755 2013-01-10 22:32:30 <Diapolo> MC1984: as I said it never happens on my machine
1756 2013-01-10 22:33:11 <Diapolo> stealth222: I'm trying the same and it's fun most of the time to help out and work on the client
1757 2013-01-10 22:35:23 <stealth222> but even if we don't have a native windows service wrapper, it could still be launched as a console application and be minimized :)
1758 2013-01-10 22:36:31 <stealth222> point is, the windows services wrapper could be added later
1759 2013-01-10 22:37:20 <MC1984> why is the estimated total blocks always quite wrong
1760 2013-01-10 22:37:27 <Diapolo> stealth222: a vision is a good thing, but I guess there is a long way :) at least
1761 2013-01-10 22:37:34 Davincij15 has quit (Ping timeout: 260 seconds)
1762 2013-01-10 22:38:11 <Diapolo> MC1984: it uses the number of blocks from connected peers, which is just not accurate
1763 2013-01-10 22:38:31 <stealth222> even more to the point, Diapolo, I would like to have a GUI that can communicate with a running instance of non-GUI bitcoind
1764 2013-01-10 22:38:39 <stealth222> and work entirely as a separate process
1765 2013-01-10 22:39:04 <MC1984> on my lan sync test, the new node said estimeted blocks was like 107k when the other node was up to date
1766 2013-01-10 22:39:14 <stealth222> that's the usage model I envision for myself, at least
1767 2013-01-10 22:39:31 <MC1984> and after it passed 107k the progress bar disappeared :/
1768 2013-01-10 22:39:34 <stealth222> and it isn't too big a stretch from there to have the GUI even run on a separate authenticated machine
1769 2013-01-10 22:40:20 <stealth222> and all that's necessary to make that happen is to add callbacks to the RPC
1770 2013-01-10 22:40:28 <stealth222> and perhaps an authentication mechanism
1771 2013-01-10 22:41:08 <sipa> stealth222: or bundle an SPV client with the wallet client
1772 2013-01-10 22:41:24 ThomasV has quit (Quit: Quitte)
1773 2013-01-10 22:41:27 <Luke-Jr> stealth222: https://en.bitcoin.it/wiki/Wallet_protocol for an ancient attempt
1774 2013-01-10 22:42:07 <sipa> stealth222: wait... are you talking about talking to a remote wallet, or have a local wallet client talking to a remote validation node?
1775 2013-01-10 22:42:09 <MC1984> does the foundation take minutes from the meetings it has with organisations
1776 2013-01-10 22:42:13 <MC1984> such as the GAO one
1777 2013-01-10 22:42:39 <BlueMatt> sipa: nfc
1778 2013-01-10 22:43:01 <sipa> BlueMatt: what does near field communication have to do with it!
1779 2013-01-10 22:43:01 <BlueMatt> sipa: are you having problems without it?
1780 2013-01-10 22:43:13 <sipa> BlueMatt: dependency on libssp-1.dll
1781 2013-01-10 22:43:15 <stealth222> sipa: either use model is potentially plausible - but a local wallet client talking to a remote validation node is probably more typical usage for endusers
1782 2013-01-10 22:43:15 <sipa> or -0
1783 2013-01-10 22:43:21 <BlueMatt> ok, Im gonna stop using that acronym now...you're the second person who's told me that
1784 2013-01-10 22:43:26 <stealth222> talking to a remote wallet is more for merchants
1785 2013-01-10 22:43:27 <sipa> lol
1786 2013-01-10 22:43:58 <BlueMatt> sipa: meh, add -static then, see if pull-tester complains, then merge
1787 2013-01-10 22:44:01 <Luke-Jr> stealth222: local wallet client talking to a remote validation node = Electrum
1788 2013-01-10 22:44:07 <BlueMatt> (oh...wait have to fix pull tester, well...Ill get back to you)
1789 2013-01-10 22:44:21 Davincij15 has joined
1790 2013-01-10 22:44:27 <Luke-Jr> sipa: why is that a problem?
1791 2013-01-10 22:44:54 * Luke-Jr never understood why some people would prefer a bloated EXE rather than a few DLLs in the same directory that users should never see anyway
1792 2013-01-10 22:44:56 TD has joined
1793 2013-01-10 22:45:03 <sipa> Luke-Jr: if someone knows how to make the nsi package contain that dll, no problem
1794 2013-01-10 22:45:24 <BlueMatt> Luke-Jr: because its easier than that ^
1795 2013-01-10 22:45:34 <Luke-Jr> huh? that's trivial
1796 2013-01-10 22:45:49 <Luke-Jr> assuming you have the DLL somewhere obvious anyhow
1797 2013-01-10 22:45:50 <BlueMatt> and its not like windows has proper dll management anyway, so it doesnt make a huge difference
1798 2013-01-10 22:46:07 <sipa> also, if you're going to put the dll in the same dir anyway, it has no advantages to keep it separate anyway
1799 2013-01-10 22:46:20 <Diapolo> sipa: I updated my stack-protector pull
1800 2013-01-10 22:46:20 <sipa> and putting it in the system dir is asking for trouble
1801 2013-01-10 22:46:44 <Luke-Jr> sipa: if it's separate, users can upgrade it themselves if they want to
1802 2013-01-10 22:46:45 <stealth222> does electrum support callbacks and notifications without having to poll the server?
1803 2013-01-10 22:46:52 <Luke-Jr> stealth222: IIRC
1804 2013-01-10 22:47:04 <Luke-Jr> stealth222: I've not used it any time recently though\
1805 2013-01-10 22:47:51 <sipa> stealth222, Luke-Jr: technically, in a way, MultiBit is also a wallet client talking to a remove validation node
1806 2013-01-10 22:47:58 <sipa> and i like that model much more
1807 2013-01-10 22:48:05 <sipa> *remote
1808 2013-01-10 22:48:13 <Luke-Jr> sipa: isn't it the same model?
1809 2013-01-10 22:48:39 <sipa> electrum relies on the server's indexing
1810 2013-01-10 22:49:15 <stealth222> ah, right - yeah, the validation node shouldn't have to do that
1811 2013-01-10 22:49:28 <stealth222> just perhaps apply some filters
1812 2013-01-10 22:49:43 <Diapolo> I'm out for now, bye
1813 2013-01-10 22:49:49 <stealth222> later, Diapolo
1814 2013-01-10 22:50:20 ovidiusoft has quit (Quit: leaving)
1815 2013-01-10 22:50:39 Diapolo has quit (Quit: Leaving.)
1816 2013-01-10 22:52:25 CodesInChaos has quit (Ping timeout: 264 seconds)
1817 2013-01-10 22:52:50 <stealth222> I also really like the idea of integrating the GUI with the desktop - so for instance, if you select a bitcoin address in an application and right-click it will give you a context menu with an option to send to it
1818 2013-01-10 22:53:15 <BlueMatt> you should already be able to click on an address and get bitcoin-qt to open ready to send
1819 2013-01-10 22:53:20 <BlueMatt> s/address/uri/
1820 2013-01-10 22:53:32 <stealth222> yeah, as a URL - sure
1821 2013-01-10 22:54:03 <stealth222> it would also be nice to be able to integrate the address book with the user's contacts
1822 2013-01-10 22:54:36 RazielZ has quit (Ping timeout: 246 seconds)
1823 2013-01-10 22:55:38 <Luke-Jr> stealth222: except that addresses are per-transaction, not per-human
1824 2013-01-10 22:55:57 <stealth222> sure - but the accounts are still per-entity
1825 2013-01-10 22:56:20 <Luke-Jr> what accounts?
1826 2013-01-10 22:56:42 da2ce7 has joined
1827 2013-01-10 22:56:52 da2ce796 has quit (Ping timeout: 276 seconds)
1828 2013-01-10 22:56:54 <stealth222> presumably when you create a new address so someone can send you bitcoins, you want to label it by the sender
1829 2013-01-10 22:57:09 <stealth222> so you can keep track of how much that sender has sent you
1830 2013-01-10 22:57:15 <Luke-Jr> stealth222: ok, I mean there will be many of those per contact in your address book
1831 2013-01-10 22:57:28 <sipa> meh, such things should be done by a payment protocol
1832 2013-01-10 22:57:39 <sipa> well, by the receiver implementation of it
1833 2013-01-10 22:57:52 <stealth222> I'm only talking about the high-level usability aspect, sipa - of course, underlying this there need to be protocols
1834 2013-01-10 22:58:05 <sipa> righty
1835 2013-01-10 22:58:42 <Luke-Jr> oh, ok
1836 2013-01-10 22:58:45 <Luke-Jr> that makes sense then
1837 2013-01-10 22:59:40 Someguy123 has quit (Excess Flood)
1838 2013-01-10 22:59:59 <stealth222> ultimately, as far as the end-user is concerned, he/she should only deal with contacts - the addresses/keys/signatures should be hidden
1839 2013-01-10 23:00:45 <stealth222> the validation nodes take care of managing that
1840 2013-01-10 23:01:11 Someguy123 has joined
1841 2013-01-10 23:01:15 <stealth222> and the wallet nodes take care of key generation/signing and grouping of accounts
1842 2013-01-10 23:01:33 <stealth222> the GUI just shows contacts
1843 2013-01-10 23:01:52 <stealth222> and balances
1844 2013-01-10 23:02:57 Someguy123 has quit (Excess Flood)
1845 2013-01-10 23:04:34 <Luke-Jr> stealth222: this is a lot of coding work to get to ;)
1846 2013-01-10 23:04:41 Someguy123 has joined
1847 2013-01-10 23:06:23 <stealth222> Luke-Jr: it's just a vision - not yet a product :)
1848 2013-01-10 23:09:52 RedEmerald has quit (Ping timeout: 276 seconds)
1849 2013-01-10 23:11:18 MrTiggr has joined
1850 2013-01-10 23:11:49 <MC1984> hmm 15 connected nodes and 220mb memory use now
1851 2013-01-10 23:14:29 RedEmerald has joined
1852 2013-01-10 23:15:02 agricocb has quit (Remote host closed the connection)
1853 2013-01-10 23:25:14 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1854 2013-01-10 23:29:35 one_zero has joined
1855 2013-01-10 23:30:27 Davincij15 has quit (Ping timeout: 255 seconds)
1856 2013-01-10 23:31:45 Insu has quit (Quit: Leaving)
1857 2013-01-10 23:37:56 <sipa> ok, first version of txid index written
1858 2013-01-10 23:38:02 <sipa> let's see how large the database gets
1859 2013-01-10 23:44:56 agricocb has joined
1860 2013-01-10 23:45:06 rdymac has joined
1861 2013-01-10 23:50:19 rdymac has quit (Quit: This computer has gone to sleep)
1862 2013-01-10 23:51:12 rdymac has joined
1863 2013-01-10 23:51:28 rdymac has quit (Remote host closed the connection)
1864 2013-01-10 23:51:34 rdymac has joined
1865 2013-01-10 23:56:25 rdymac has quit (Ping timeout: 252 seconds)
1866 2013-01-10 23:59:28 maaku has quit (Quit: maaku)
1867 2013-01-10 23:59:43 <sipa> should be around 450 MB