1 2013-02-24 00:00:10 <amiller> for the address->utxo that might matter more
   2 2013-02-24 00:00:28 <amiller> since some addresses collect a lot of unspent outputs
   3 2013-02-24 00:00:45 <petertodd> Yeah, I'm thinking scriptPubKey->utxo should use H(scriptPubKey) as the key
   4 2013-02-24 00:01:14 <petertodd> Although I came up with an example where being able to query multisig's would be really usefull... but alas, probably have to leave that behind.
   5 2013-02-24 00:01:34 <petertodd> (even asking for scriptPubKey is pushing it, only some applications need it)
   6 2013-02-24 00:02:24 <amiller> meh i'm starting to agree
   7 2013-02-24 00:02:34 <petertodd> worse is better :)
   8 2013-02-24 00:04:13 <HM> hmm
   9 2013-02-24 00:04:52 <HM> isn;t scriptPubKey essentially under the control of anyone who creates a transaction
  10 2013-02-24 00:05:12 <HM> If you just hash it they could potentially manipulate your tree
  11 2013-02-24 00:05:22 <amiller> there isn't a whole lot they could do to manipulate it
  12 2013-02-24 00:05:26 <amiller> but you could have a target attack
  13 2013-02-24 00:05:31 <amiller> like lets suppose there's an address that's really popular
  14 2013-02-24 00:05:35 <amiller> like the bitcoin foundation donation address
  15 2013-02-24 00:05:45 <gmaxwell> sure, and? thats why the tree must be self balancing.. but moreover, if the key is H(scriptPubKey) then any unbalancing attack reduces to a partial preimage attack on the hash.
  16 2013-02-24 00:06:05 <petertodd> yes, but at worst they can force a depth of 256, which just screws themselves over w/ proof length
  17 2013-02-24 00:06:12 <amiller> then itw ould be really easy for someone to insert something in this tree that would make it take 5x longer to process those
  18 2013-02-24 00:06:19 <petertodd> 256 depth isn't going to be a big problem for processing I suspect
  19 2013-02-24 00:06:23 <petertodd> hashing is fast
  20 2013-02-24 00:06:37 <amiller> agreed but it would be a lot harder to do if the tree were self balancing
  21 2013-02-24 00:06:45 <amiller> whereas it would be easier to do with at rie
  22 2013-02-24 00:06:56 <petertodd> after all, 256 depth is the same as hashing ~8KiB of data or so
  23 2013-02-24 00:07:08 <petertodd> it's ECDSA that's slow
  24 2013-02-24 00:07:17 <amiller> hmm, maybe this doesn't hold even if you'd have to do a partial preimage attack to do so
  25 2013-02-24 00:07:35 <gmaxwell> amiller: can always send to the _same_ address to bloat it.
  26 2013-02-24 00:07:40 <HM> i was thinking more potential for collision.
  27 2013-02-24 00:07:46 <amiller> yeah
  28 2013-02-24 00:08:20 <petertodd> well, a UTXO scriptPubKey will basically look like scriptPubKey->(bunch of steps)->UTXO set for the scriptPubkey->bunch of steps->txout:vout
  29 2013-02-24 00:08:35 <amiller> oh right so that's based on the scriptpubkey that can spend it
  30 2013-02-24 00:08:41 <petertodd> exactly
  31 2013-02-24 00:08:49 <amiller> so you could just send somethign to a modified address and make it harder for them
  32 2013-02-24 00:08:58 <petertodd> and, at each step sums of vout values
  33 2013-02-24 00:09:18 <gmaxwell> yea, so you get a proof of sum coins at the top.
  34 2013-02-24 00:09:24 <amiller> ok so then this is a reason why a deterministically-balanced binary tree is preferable to a tree
  35 2013-02-24 00:09:31 <petertodd> yeah, a real attacker might manage a 64-bit chosen prefix
  36 2013-02-24 00:09:42 <amiller> to a radixtree , at least in the case of H(scriptpubkey)->utxo
  37 2013-02-24 00:10:21 <petertodd> ok, but before you even start, your deterministically-balanced tree is now subject to bugs with insert order, rather than just the content of the set
  38 2013-02-24 00:10:28 <petertodd> Why raise the consensus-breaking surface?
  39 2013-02-24 00:10:38 <amiller> it doesn't matter because the insert order is already committed
  40 2013-02-24 00:10:44 <petertodd> I *really* think we'll find that CPU time isn't our biggest cost.
  41 2013-02-24 00:10:53 <HM> Regardless of all this work, can the unspent database still not be huge?
  42 2013-02-24 00:11:07 <gmaxwell> petertodd: you must have tests that are sufficient to detect bugs or _any_ implementation is toast.
  43 2013-02-24 00:11:34 <gmaxwell> HM: sure, it can be large. — though its growth is bounded by the blockchain growth.
  44 2013-02-24 00:11:42 <gmaxwell> (and by the smallest outputs we allow)
  45 2013-02-24 00:11:46 <petertodd> gmaxwell: Exactly. Easier if a test is just "here is your set of txouts, what hash do we get?"
  46 2013-02-24 00:12:23 <petertodd> gmaxwell: And the requirement for proofs to be made of this stuff bothers me a bit... I'd want to be sure we don't leave ourselves open to some subtle attack there.
  47 2013-02-24 00:12:49 <petertodd> gmaxwell: Especially an attack based on a bug that due to consensus we can't fix easilly...
  48 2013-02-24 00:13:04 <gmaxwell> petertodd: but not much harder to have long complicated update sequences.  I mean, I shouldn't be arguing this too much— falures to adequately test incremental updates of a 4-ary prefix-trie caused large internet-wide outages for my prior employer two years ago. :P
  49 2013-02-24 00:13:05 <amiller> petertodd, that's an argument in favored of having very structured definition of the protocol rather than a C++ implementation
  50 2013-02-24 00:13:22 TradeFortress has joined
  51 2013-02-24 00:13:34 <HM> I guess if the entire world used Bitcoin you'd likely only have a relatively manageable amounts on unspent inputs. 6 billion people x whatever they haven't spent in relatively managable chunks
  52 2013-02-24 00:13:39 <gmaxwell> petertodd: but really, any proposal like this will need a set of test vectors which hits every branch in a reasonable implementation. We can adequately test it.
  53 2013-02-24 00:13:40 <amiller> not an argument in favor of the slightly-easier-to-implement-a-toy-in-C trie vs a guaranteed balanced balanced  tree
  54 2013-02-24 00:13:50 <petertodd> amiller: Yeah, like, if we had some way of taking that definition, and, like turning it into executable code, maybe called a compiler or something... You're right, but good luck.
  55 2013-02-24 00:14:13 <petertodd> amiller: If it's so better, get it implemented!
  56 2013-02-24 00:14:26 <amiller> petertodd, i'm taking a break to argue! personal time!
  57 2013-02-24 00:14:35 <HM> you can still have potentially trillions of unspent transactions though... right?
  58 2013-02-24 00:14:46 <petertodd> amiller: Lol, well I took a break to put a rick-roll in the blockchain so...
  59 2013-02-24 00:14:48 <amiller> meanwhile i encourage you to do your merkle trie implementation
  60 2013-02-24 00:15:11 <amiller> so far my crap python code (thanks for noticing it HM!) is the only toy prototype so far
  61 2013-02-24 00:15:11 <petertodd> HM: yes, it's a huge long-term worry. The UTXO set access needs to be sufficiently fast, 10mins/n fast.
  62 2013-02-24 00:15:16 <amiller> so if you want to benchmark against it you can :3
  63 2013-02-24 00:15:31 <petertodd> HM: Remember it influences your orphan rate if you can't process it fast enough.
  64 2013-02-24 00:15:42 <petertodd> amiller: No pressure. :P
  65 2013-02-24 00:15:54 <amiller> etotheipi is supposed to be doing one too
  66 2013-02-24 00:16:20 <HM> It is a worry because 21 million coins doesn't serve 6 billion people very well unless you have tiny denominates. each atom of bitcoin can exist in its own unspent transaction
  67 2013-02-24 00:16:27 <petertodd> amiller: Frankly it bothers me that etotheipi hasn't realized that merkle sums are useful, or that people will make to make proofs out of this stuff.
  68 2013-02-24 00:16:34 <HM> you could be looking at petabytes
  69 2013-02-24 00:16:55 <Goonie> BlueMatt: thanks for updating the Ubuntu PPA (-:
  70 2013-02-24 00:16:56 <gmaxwell> HM: 'petabytes' is actually the worst case where every satoshi is its own output.
  71 2013-02-24 00:17:01 <petertodd> HM: 210 million billion satoshi's makes for a nice upper limit on the UTXO set.
  72 2013-02-24 00:17:02 <gmaxwell> (44 PB I think?)
  73 2013-02-24 00:17:19 <HM> ...
  74 2013-02-24 00:17:20 RBecker is now known as rbecker
  75 2013-02-24 00:17:28 <gmaxwell> HM: it's not that large. :)
  76 2013-02-24 00:17:32 <gmaxwell> unfortunately no such limit exists at the moment.
  77 2013-02-24 00:17:37 <petertodd> gmaxwell: Yeah, you were thinking log2(n) access times for UTXO should be ok right? Because I was saying how log2(n) is reasonable physically speaking.
  78 2013-02-24 00:17:41 <gmaxwell> since you can author 0 value UTXO.
  79 2013-02-24 00:17:57 <amiller> petertodd, the one cool thing about my python code was that it's general enough to support sums of things
  80 2013-02-24 00:18:08 <amiller> my demonstration was that i stored the total number of utxos in each node
  81 2013-02-24 00:18:20 <amiller> i used that to select uniformly randomly from the utxos
  82 2013-02-24 00:18:27 <petertodd> gmaxwell: Actually... so making 0-value UTXO's unspendable has no economic impact...
  83 2013-02-24 00:18:28 <HM> you need to forget storing transactions and keep a record of how much someone has directly. :P
  84 2013-02-24 00:18:37 monkeynipples has quit (Remote host closed the connection)
  85 2013-02-24 00:18:39 <petertodd> amiller: Lol, nice!
  86 2013-02-24 00:18:45 <gmaxwell> amiller: oh thats slick
  87 2013-02-24 00:18:51 <amiller> so your point about sums and stuff is spot on
  88 2013-02-24 00:18:53 <gmaxwell> (the uniform random utxo selection)
  89 2013-02-24 00:18:54 <amiller> super useful
  90 2013-02-24 00:19:01 <gmaxwell> The sums stuff is mostly useful for inflation proofing.
  91 2013-02-24 00:19:32 <gmaxwell> I can give you a utxo root that sums to 10 million coin, and you can randomly check some of the sums and be confident that its true to some degree.
  92 2013-02-24 00:19:48 <amiller> that's pretty cool
  93 2013-02-24 00:19:50 HiroWhite has quit (Ping timeout: 260 seconds)
  94 2013-02-24 00:19:59 <gmaxwell> so a SPV node would know that the prior participants hadn't printed more coin than you believed they should have.
  95 2013-02-24 00:20:05 <petertodd> Well, more importantly, anyone who'se checked all the sums can create a fraud challenge saying "why don't these add up?"
  96 2013-02-24 00:20:17 <amiller> oh yeah
  97 2013-02-24 00:20:19 <amiller> so if there ever is a mistake
  98 2013-02-24 00:20:23 <amiller> you can generate a short proof of the mistake
  99 2013-02-24 00:20:27 <petertodd> Exactly, you just need one honest node.
 100 2013-02-24 00:20:28 <amiller> and it will be pretty compelling
 101 2013-02-24 00:20:30 HiroWhite has joined
 102 2013-02-24 00:20:35 <gmaxwell> petertodd: you multiply those two, that random selection can result in everyone knowing the mistake.
 103 2013-02-24 00:20:53 <gmaxwell> so your one honest node can be distributed among the whole network.
 104 2013-02-24 00:21:01 <petertodd> https://bitcointalk.org/index.php?topic=137933.0 <- my worked example of how to do this
 105 2013-02-24 00:21:23 <amiller> you're retep oh i get it
 106 2013-02-24 00:21:33 <gmaxwell> If each honest participant is 1/Nth altruistic, then you get your one honest-altrustic node that way.
 107 2013-02-24 00:22:01 <petertodd> gmaxwell: See, *anything* that assumes that a random selection will find the problem really worries me... A: you might be unlucky. B: More importantly, there may be a way to influence that random selection, so you get away for your fraud a lot longer.
 108 2013-02-24 00:22:14 <petertodd> amiller: Yes, but do you know why I'm retep?
 109 2013-02-24 00:22:19 <gmaxwell> amiller: I like your sum count though, you'd need that to do proof-of-memory.
 110 2013-02-24 00:22:33 <petertodd> ooh, good point!
 111 2013-02-24 00:23:04 <amiller> another reason why i'm working so much at this nice generic ads library is that it turns out all the fanciest crypto things that we might want 10 years in the future
 112 2013-02-24 00:23:07 <petertodd> Ok, so we want proof-of-fees, proof-of-memory, proof-of-utxo, and proof-of-scriptPubKey value
 113 2013-02-24 00:23:13 <gmaxwell> petertodd: of course, I'd also want there to be nodes that check all of it... and I'd want the random density to be a large multiple of whats 'needed'... but the point is still that you can get more checking by not requring every checker to have 100%.
 114 2013-02-24 00:23:18 <amiller> are all based on the same sort of trick as merkleizing data structures and carrying things like the sums up to the parents
 115 2013-02-24 00:23:31 <amiller> they just add to that hash functions with slightly special properties
 116 2013-02-24 00:23:37 <petertodd> gmaxwell: Yeah, random checking gets us speed, checking every one makes sure it actually happens.
 117 2013-02-24 00:23:53 <petertodd> gmaxwell: Broadcasting frauds can be a DoS attack after all, if a not very efficient one.
 118 2013-02-24 00:24:05 <gmaxwell> petertodd: well proof of memory gets you proof that at least the miners are checking everything, random checking makes it unprofitable for miners to cheat.
 119 2013-02-24 00:24:09 <petertodd> amiller: What special problems?
 120 2013-02-24 00:24:13 <petertodd> *properties
 121 2013-02-24 00:24:28 <petertodd> gmaxwell: Ah, yes, proof of memory is good there.
 122 2013-02-24 00:24:35 <gmaxwell> if the fraud is invalid you ban the peer. not a big deal.
 123 2013-02-24 00:24:44 <gmaxwell> if its valid— well you ignore it unless its against your best chain.
 124 2013-02-24 00:24:46 <petertodd> gmaxwell: I do like the utxo-hard PoW idea.
 125 2013-02-24 00:25:05 <amiller> petertodd a demo of that is also in myp ython code!
 126 2013-02-24 00:25:15 <petertodd> Lol, where is your python code?
 127 2013-02-24 00:25:34 <amiller> https://github.com/amiller/redblackmerkle/blob/proofofthroughput/proofofthroughput.py
 128 2013-02-24 00:25:38 frosks has joined
 129 2013-02-24 00:25:57 <petertodd> Thanks
 130 2013-02-24 00:26:08 <gmaxwell> (also the sum count should make a self-balancing tree easier to get right)
 131 2013-02-24 00:26:59 bitminerASIC has joined
 132 2013-02-24 00:27:19 <gmaxwell> amiller: you see the latest PPcoin 'advancement' to POS?
 133 2013-02-24 00:27:20 <HM> amiller: "Many miners currently don't bother to maintain one." ?
 134 2013-02-24 00:27:50 <amiller> HM, i apologize that's an unfounded claim
 135 2013-02-24 00:28:00 <petertodd> gmaxwell: I saw Gavin's (rightfully) nasty message...
 136 2013-02-24 00:28:02 <amiller> at the time i had read an article about a botnet miner that appeared not to have a utxo set because it only mined empty blocks
 137 2013-02-24 00:28:04 monkeynipples has joined
 138 2013-02-24 00:28:24 <petertodd> amiller: That was last year, stopped in late march or so.
 139 2013-02-24 00:28:25 <gmaxwell> petertodd: I went and looked at the code. It's true that they fixed the problem.
 140 2013-02-24 00:28:26 axhlf has quit (Ping timeout: 252 seconds)
 141 2013-02-24 00:28:34 <gmaxwell> But they fixed it by adding more centeralization.
 142 2013-02-24 00:28:43 <petertodd> Sheesh... what was the fix?
 143 2013-02-24 00:28:46 <gmaxwell> at least if I read it correctly.
 144 2013-02-24 00:29:06 <gmaxwell> so the problem was that POS was a lie: you could just spend more CPU cycles to boost your POS and mine faster than your real stake allows.
 145 2013-02-24 00:29:17 <gmaxwell> (e.g. searching more timestamps or whatever)
 146 2013-02-24 00:29:27 <petertodd> Yeah, the hybrid thing seemed silly to me.
 147 2013-02-24 00:30:08 <gmaxwell> they solved this by constraining the range that you could use for nonces/timestamps ... and the solved the deadlock that produces when no one can produce a POS block by having their centeral broadcasted checkpoints give nonces for use in POS mining.
 148 2013-02-24 00:31:06 <gmaxwell> (I suppose thats less bad than the centerally controlled broadcast checkpoints ... but uh they said the checkpoints were only a bootstrapping thing and would go away)
 149 2013-02-24 00:31:10 <petertodd> You know, I was thinking, what are the ramifications of making a system based on best-block replacement? IE, if you get another best block meeting the PoW, you replace it if the other block has a better secondary Po?
 150 2013-02-24 00:31:26 <gmaxwell> slows convergence.
 151 2013-02-24 00:31:33 <petertodd> gmaxwell: No matter what, it's still centralization. Hopefully they at least were honest about it.
 152 2013-02-24 00:31:47 <petertodd> gmaxwell: Sure, what else does it do? Slowing convergence could be acceptable.
 153 2013-02-24 00:31:52 <gmaxwell> they don't seem to have disclosed how that worked at all. (or of they did, I missed it)
 154 2013-02-24 00:31:59 <petertodd> very bad...
 155 2013-02-24 00:32:03 bitminerASIC has quit (Quit: Page closed)
 156 2013-02-24 00:32:15 <gmaxwell> petertodd: well, makes an economic incentive to keep on trying for a better secondary instead of advancing.
 157 2013-02-24 00:32:43 <petertodd> gmaxwell: Yes, but we already have one of those with fees, at least in the future.
 158 2013-02-24 00:33:00 <petertodd> gmaxwell: With the blocksize limit though, there comes a point when your block is full...
 159 2013-02-24 00:33:13 <gmaxwell> yea. sure. but it makes it worse.. right now to split a feeed block I have to get ahead of it, not just match it at the primary pow.
 160 2013-02-24 00:33:35 <gmaxwell> lol: crazy, I do believe you just hit another blocksize limit argument.
 161 2013-02-24 00:33:55 <petertodd> Oh for sure, but it could be used as some sort of way to do a decent PoW/Po? hybrid in a reasonable way.
 162 2013-02-24 00:34:01 <petertodd> It's a lovely argument.
 163 2013-02-24 00:34:29 <petertodd> Alright, bitcoin-dev here I come...
 164 2013-02-24 00:34:49 <HM> petertodd: are you sure you don't have a compsci degree?
 165 2013-02-24 00:34:58 <HM> you might have slept through it
 166 2013-02-24 00:35:10 <HM> and passed with honours :|
 167 2013-02-24 00:35:47 <gmaxwell> petertodd: I'd think what we should probably eventually have is a very cheap POM as just a block validity rule.
 168 2013-02-24 00:35:51 <petertodd> http://upload.wikimedia.org/wikipedia/en/a/a7/Ocad.jpg is the school I went to
 169 2013-02-24 00:36:01 <petertodd> POM?
 170 2013-02-24 00:36:12 <petertodd> oh, memory
 171 2013-02-24 00:36:26 <gmaxwell> e.g. coinbase contains some token which is a provable utxo query result based on the prevhash.
 172 2013-02-24 00:37:00 <gmaxwell> but totally memorless miners aren't much of a concern today and maybe will never be.
 173 2013-02-24 00:37:12 <petertodd> HM: apparently my thesis there had the most actual math equations in any thesis ever submitted in the history of the school. I outlined how Newton could have come up with the gravity equation from first principles...
 174 2013-02-24 00:37:21 <HM> petertodd: so you decended from the mothership above? :P
 175 2013-02-24 00:37:59 <petertodd> HM: Ha, kinda... the top part of the school is the design half, the bottom part is the older art side of things. I started in industrial design, quit that, and went to integrated media.
 176 2013-02-24 00:38:09 <petertodd> gmaxwell: Sounds pretty reasonable to me.
 177 2013-02-24 00:38:24 <petertodd> gmaxwell: With a sufficiently small UTXO set hopefully not...
 178 2013-02-24 00:39:03 <HM> how do you plan to keep the utxo set small?
 179 2013-02-24 00:39:05 <gmaxwell> petertodd: I think a proof of throughput is too big a break from what bitcoin is— esp with now millions spend on SHA256 POWers.
 180 2013-02-24 00:39:44 <amiller> hence proof-of-throughput is a topic for researchcoin
 181 2013-02-24 00:39:54 <petertodd> gmaxwell: Pure, sure, but you were just talking about some forced proof that you have the UTXO set at all.
 182 2013-02-24 00:40:05 <petertodd> It'd be a fixed PoM
 183 2013-02-24 00:40:44 <gmaxwell> petertodd: yea, thats how I'd distinguish PoT and PoM. I think PoM is realistically compatible with bitcoin.
 184 2013-02-24 00:41:23 <petertodd> gmaxwell: It can even be a soft-fork with a replacement rule. Blocks without PoM get replaced by ones with, if they are at the tip of the chain.
 185 2013-02-24 00:41:41 <HM> wouldn't a simple way to prove someone had the utxo set be just to ask for a random utxo
 186 2013-02-24 00:41:50 <petertodd> HM: No, because who does the asking?
 187 2013-02-24 00:42:02 <HM> whoever needs to know :|
 188 2013-02-24 00:42:02 <gmaxwell> oh, I like the replacement rule as a soft forking thing, we'll have to remember that.
 189 2013-02-24 00:42:17 <gmaxwell> HM: everyone who needs to know if a block is valid or not needs to know.
 190 2013-02-24 00:42:39 <amiller> there's no way to make a pom useful without including it in the pow
 191 2013-02-24 00:42:47 <amiller> because it's trivial jsut to have a service that produces valid poms that anyone can use
 192 2013-02-24 00:42:53 <amiller> it provides no strong protection against anything
 193 2013-02-24 00:43:12 copumpkin has quit (Ping timeout: 252 seconds)
 194 2013-02-24 00:43:30 <gmaxwell> amiller: the service would charge for it— of course. why give away something that hurts security?
 195 2013-02-24 00:43:47 <amiller> civil disobedience
 196 2013-02-24 00:43:48 copumpkin has joined
 197 2013-02-24 00:43:50 <petertodd> amiller: Yes, but even forcing the creation of such a service means miners can at least use it to include a few blocks - IE it kills the bot-net reason to *not* do that.
 198 2013-02-24 00:43:53 <gmaxwell> I guess thats a point the service would charge 1/Nth though.
 199 2013-02-24 00:44:03 <HM> wait, how does proof that a miner has the unspent set prove they've checked the block for validity?
 200 2013-02-24 00:44:18 <gmaxwell> HM: it doesn't but it proves that the cost of having a copy didn't prevent them from checking.
 201 2013-02-24 00:44:23 <petertodd> Remember that the bot-net did that because it meant they could have no local storage at all, nor did they have to rely on pools.
 202 2013-02-24 00:44:27 <gmaxwell> HM: if they have a copy, then checking is cheap.
 203 2013-02-24 00:44:38 <HM> right
 204 2013-02-24 00:44:41 <gmaxwell> petertodd: well, that was my speculation. We don't know if that was true.
 205 2013-02-24 00:44:48 <gmaxwell> (unless you know something I don't know)
 206 2013-02-24 00:44:58 <petertodd> gmaxwell: Shit, I'm revealing too much... :P
 207 2013-02-24 00:45:04 <gmaxwell> :P
 208 2013-02-24 00:45:04 <HM> and the proof requires querying it to produce the merkle root you're discussing
 209 2013-02-24 00:45:51 <gmaxwell> HM: the POM idea would be that the prior block is your 'query' and the new block must include an answer.  So people who can answer that question have a huge advantage in mining.
 210 2013-02-24 00:46:38 <gmaxwell> Amiller points out that someone might just run a public query service. Mooting it. Petertood points out that it's not totally mooted, if there is a public query service you can use that to actually validate things.
 211 2013-02-24 00:46:43 <amiller> it's ridiculously easy to just have your CnC broadcast it too
 212 2013-02-24 00:47:10 <gmaxwell> One Idea I had for a POM that didn't actually require a UTXO set (this was what I orignally proposed in the 1tx miner thread) is that the POM is just the hash of all the txins consumed in the prior block.
 213 2013-02-24 00:47:54 <gmaxwell> Which basically means that you did all the query work to validate the prior block. The only thing you may not have done is actually performed the script validation. But that would be so stupid... you'd save no cost except some coding time at that point.
 214 2013-02-24 00:48:38 <amiller> the main argument for PoT is that it rewards the 'provers', meaning it pays the costs for the machines that publicly respond to these queries
 215 2013-02-24 00:48:47 <amiller> no one can make much money operating a proof-provider
 216 2013-02-24 00:48:49 <gmaxwell> ironically, we seem to have fixed the problem with the introduction of P2SH.. orphaned the shit out of that SOB.
 217 2013-02-24 00:49:19 <gmaxwell> amiller: I'm not arguing that PoT isn't a good idea. Only that its too distinct from bitcoin for it to be a remotely near term consideration.
 218 2013-02-24 00:49:36 <gmaxwell> huge QC's make the mining control loop go wonky and perhaps then. :P
 219 2013-02-24 00:49:37 <amiller> if it's not a good near consideration then does that make it a long term consideration
 220 2013-02-24 00:49:55 treb is now known as ainfo
 221 2013-02-24 00:49:59 <gmaxwell> amiller: yea, perhaps— or just a tool for an alternative system.
 222 2013-02-24 00:50:02 <petertodd> gmaxwell: Though now that P2SH is supported... he could probably use the same strategy again with success!
 223 2013-02-24 00:50:03 <amiller> i acknowledge the horrible problem it would have of meaning that investment in hash power would not be useful there
 224 2013-02-24 00:50:49 <gmaxwell> petertodd: hush.
 225 2013-02-24 00:51:18 <gmaxwell> petertodd: yea, his problem was mostly other broken miners producing orphans to trap him.
 226 2013-02-24 00:52:15 <petertodd> gmaxwell: Which frankly makes me wonder if that was really what stopped him...
 227 2013-02-24 00:53:14 <gmaxwell> or if he really was a botnet and not some other kind of ignorant.
 228 2013-02-24 00:53:58 <gmaxwell> I've seen (small) pool operators who believed that their mining was slowed down proportional to the number of txn the blocks had.
 229 2013-02-24 00:54:04 <petertodd> gmaxwell: Tx fees are low - they might have just figured the decrease in orphan rate was worth it.
 230 2013-02-24 00:54:06 Hashdog has quit (Read error: Connection reset by peer)
 231 2013-02-24 00:54:15 <petertodd> It crops up in the forums a lot.
 232 2013-02-24 00:54:59 <HM> gmaxwell: where in reality it's O(log(n)) ?
 233 2013-02-24 00:55:15 <HM> and the difficulty dwarfs everything else
 234 2013-02-24 00:55:18 <petertodd> HM: Compared to mining it's O(1)
 235 2013-02-24 00:55:27 <HM> right
 236 2013-02-24 00:55:36 <petertodd> At least with 1MiB blocks...
 237 2013-02-24 00:55:54 <HM> yeah i've followed the block size debate a bit
 238 2013-02-24 00:56:05 <gmaxwell> yea, it's O(1) even at minimum difficulty. Minimum difficulty requires 2^32 hashing operations ... :P
 239 2013-02-24 00:56:14 <petertodd> HM: you commented in it? I don't think I know your name on the forums.
 240 2013-02-24 00:56:25 <HM> I'm not on the forums
 241 2013-02-24 00:56:27 <petertodd> ah
 242 2013-02-24 00:56:32 <petertodd> good life choice
 243 2013-02-24 00:56:58 <petertodd> gmaxwell: Reminds me, ever noticed how hard the PoW for the genesis block was?
 244 2013-02-24 00:57:15 <HM> I'm not qualified to comment, i'm trying to keep up with the interesting people here the best i can. i find it interesting and challenging. gmaxwell, sipa and others here are very good hosts
 245 2013-02-24 00:57:20 D34TH has joined
 246 2013-02-24 00:57:20 D34TH has quit (Changing host)
 247 2013-02-24 00:57:20 D34TH has joined
 248 2013-02-24 00:57:29 <amiller> HM, i'm enjoying wathcing you ask questions in here ;D
 249 2013-02-24 00:57:39 <petertodd> HM: if only more people took your wise position...
 250 2013-02-24 00:58:23 <HM> there's a new fascinating idea discussed here every day it seems
 251 2013-02-24 00:58:44 <HM> hierarchical wallets, merkle trees for utxos, i forget ...just lots of stuff
 252 2013-02-24 00:59:30 <amiller> bitcoin is by far the most ineresting thing ever
 253 2013-02-24 00:59:40 <gmaxwell> petertodd: hm? it was diff 1, no?
 254 2013-02-24 01:00:26 <HM> split keys used in vanitygen is another interesting thing i learned here
 255 2013-02-24 01:00:37 <petertodd> gmaxwell: Diff 1 by definition, but the actual PoW hash was significantly better than diff 1
 256 2013-02-24 01:00:39 <HM> and sipa got some kinks out of EC out for me
 257 2013-02-24 01:01:04 <amiller> does it highlight you every time someone says hm
 258 2013-02-24 01:01:35 <phantomcircuit> amiller, lets find out
 259 2013-02-24 01:01:39 <phantomcircuit> hm
 260 2013-02-24 01:01:41 <amiller> hm
 261 2013-02-24 01:01:44 D34TH has quit (Ping timeout: 252 seconds)
 262 2013-02-24 01:01:46 <gmaxwell> petertodd: it's not that much better.
 263 2013-02-24 01:02:31 ymirhotfoot has joined
 264 2013-02-24 01:02:36 <HM> "hm" highlights for me yeah
 265 2013-02-24 01:02:47 <HM> hmm has 2 m's damnit :P
 266 2013-02-24 01:02:53 fishfish has quit (Quit: Leaving...)
 267 2013-02-24 01:02:56 <petertodd> I did the numbers, and it looked like Satoshi had run his client for about a week.
 268 2013-02-24 01:03:14 <petertodd> So, if he had enough to do diff 1 mining, that implies early 10x better.
 269 2013-02-24 01:03:23 <petertodd> Could be just chance of course, but I can see the logic there.
 270 2013-02-24 01:03:33 <petertodd> Matches the timestamps too.
 271 2013-02-24 01:04:11 <Luke-Jr> hm
 272 2013-02-24 01:04:53 <HM> lol
 273 2013-02-24 01:05:45 <gmaxwell> petertodd: hm perhaps he actually just left it running from the time of the announcement to the time of the relase... and released with the best genesis he had so far.
 274 2013-02-24 01:06:06 <petertodd> gmaxwell: Exactly what I'm thinking.
 275 2013-02-24 01:06:49 <gmaxwell> the miner in the original code/binaries was really quite slow. like .. 40kh/s on period hardware.
 276 2013-02-24 01:06:57 <phantomcircuit> HM, you realize you are going to have to change your handle now right?
 277 2013-02-24 01:07:05 <gmaxwell> hm...
 278 2013-02-24 01:07:37 <petertodd> hm...
 279 2013-02-24 01:07:40 <phantomcircuit> aha
 280 2013-02-24 01:07:42 <Luke-Jr> hm?
 281 2013-02-24 01:07:46 <petertodd> hm!
 282 2013-02-24 01:07:50 <Luke-Jr> O.o
 283 2013-02-24 01:07:54 <petertodd> a hm!
 284 2013-02-24 01:08:13 <HM> perhaps I should charge royalties
 285 2013-02-24 01:08:34 <petertodd> what, a satoshi each? we'll just make low-value txouts non-standard, sucker
 286 2013-02-24 01:08:45 <gmaxwell> HM: I'd recommend changing your name to and if you're going to go that route, or maybe I.
 287 2013-02-24 01:09:21 <petertodd> HM: or change your name to I?
 288 2013-02-24 01:10:32 <HM> I could just change it to 'hash'
 289 2013-02-24 01:10:35 <HM> i'd be rich in a day
 290 2013-02-24 01:10:50 <petertodd> nah, we'll all just start talking about digests instead
 291 2013-02-24 01:11:23 <petertodd> change it to pubkey
 292 2013-02-24 01:12:20 BCBot` has quit (Ping timeout: 264 seconds)
 293 2013-02-24 01:17:01 zxcanon has quit (Quit: Page closed)
 294 2013-02-24 01:28:44 alexwaters11 has joined
 295 2013-02-24 01:30:01 alexwaters1 has quit (Ping timeout: 256 seconds)
 296 2013-02-24 01:31:50 D34TH has joined
 297 2013-02-24 01:31:50 D34TH has quit (Changing host)
 298 2013-02-24 01:31:51 D34TH has joined
 299 2013-02-24 01:32:00 <jgarzik> hum
 300 2013-02-24 01:33:08 <ymirhotfoot> ;;ticker
 301 2013-02-24 01:33:09 <gribble> BTCUSD ticker | Best bid: 29.58066, Best ask: 29.79000, Bid-ask spread: 0.20934, Last trade: 29.57147, 24 hour volume: 70705.75085715, 24 hour low: 28.00000, 24 hour high: 30.49655, 24 hour vwap: 29.01619
 302 2013-02-24 01:35:04 <kuzetsa> gmaxwell: privmsg?
 303 2013-02-24 01:35:09 <ymirhotfoot> ;;bc,stats
 304 2013-02-24 01:35:12 <gribble> Current Blocks: 222784 | Current Difficulty: 3651011.630693214 | Next Difficulty At Block: 223775 | Next Difficulty In: 991 blocks | Next Difficulty In About: 5 days, 22 hours, 25 minutes, and 8 seconds | Next Difficulty Estimate: 4317874.20008 | Estimated Percent Change: 18.26515
 305 2013-02-24 01:35:19 monkeynipples has quit (Remote host closed the connection)
 306 2013-02-24 01:37:29 <jgarzik> ymirhotfoot: /msg gribble please
 307 2013-02-24 01:39:51 copumpkin has quit (Ping timeout: 252 seconds)
 308 2013-02-24 01:40:26 copumpkin has joined
 309 2013-02-24 01:40:34 <ymirhotfoot> jgarzik, oi, I must read the manual, my last attempt to msg gribble failed, oi.
 310 2013-02-24 01:41:26 <ymirhotfoot> ah, perhaps you wish me to speak privately with quagmire, ah, yes
 311 2013-02-24 01:42:52 <ymirhotfoot> Thanks, jgarzik, got it, ole gribble is now cunningly in a low voice talking to me in a SEKRIT EMACS WINNER!
 312 2013-02-24 01:48:42 ymirhotfoot has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 313 2013-02-24 01:57:51 BTC_Bear has joined
 314 2013-02-24 02:03:11 <muhoo> petertodd: glad to hear there's someone doing bitcoin stuff in haskell
 315 2013-02-24 02:03:40 ymirhotfoot has joined
 316 2013-02-24 02:05:11 <gmaxwell> s/petertodd/amiller/
 317 2013-02-24 02:21:03 RazielZ has quit (Ping timeout: 246 seconds)
 318 2013-02-24 02:26:26 <muhoo> ah
 319 2013-02-24 02:26:45 <muhoo> ok, i've googled, what is UTX0 ?
 320 2013-02-24 02:27:28 <amiller> muhoo, if you're interested have a look https://github.com/amiller/generic-ads
 321 2013-02-24 02:27:36 ymirhotfoot has quit (Ping timeout: 252 seconds)
 322 2013-02-24 02:27:49 <amiller> utxo is the unspent txoutput index
 323 2013-02-24 02:27:57 ymirhotfoot has joined
 324 2013-02-24 02:28:02 <muhoo> amiller: thanks, and thanks.
 325 2013-02-24 02:28:04 <amiller> if you're someone interested in validating transactions, whether you're a miner or a small client
 326 2013-02-24 02:28:11 <amiller> it's not enough to keep a copy of the blockchain
 327 2013-02-24 02:28:17 <amiller> you additionally need to keep a copy of the UTXO index
 328 2013-02-24 02:28:30 <amiller> technically you don't need either
 329 2013-02-24 02:28:37 <amiller> if all you had was the hash of the previous block....
 330 2013-02-24 02:28:54 <amiller> technically someone could walk you through a proof that each txout exists in the chain and hasn't been spent yet... but that would be ridiculously slow.
 331 2013-02-24 02:29:28 <amiller> so the great idea (it was gmaxwell's idea first like two years ago, i think) is to store a commitment root hash for a search tree that provides exactly that index
 332 2013-02-24 02:29:49 <amiller> this means you could verify pretty efficiently even if you didn't have a lot of storage
 333 2013-02-24 02:29:57 agricocb has quit (Remote host closed the connection)
 334 2013-02-24 02:30:11 <muhoo> cool. i didn't know that the first (OK, 0th) output is always the unspent one.
 335 2013-02-24 02:30:52 <gmaxwell> yea, I think thats my one big original idea in this space... and it'll probably not turn out to be original. Bytecoin had something in this space which wasn't as possible (didnt have logn(x) proofs).
 336 2013-02-24 02:32:56 chmod755 has quit (Quit: chmod755)
 337 2013-02-24 02:35:17 fishfish has joined
 338 2013-02-24 02:37:30 <gmaxwell> well, I guess using the 'type-2' property for wallets, but I half stole that idea from bytecoin— who was intentionally secretive about it. He mentioned that it was possible to securely generate vanity addresses but declined to say how, in case he wanted to make a business out of it. That caused me to go figure out how, and I realized it would be useful for online merchant wallets.
 339 2013-02-24 02:38:05 <HM> by split keys?
 340 2013-02-24 02:39:45 <HM> i don't see how you can make a business out of that without revealing how you're doing it
 341 2013-02-24 02:40:08 <gmaxwell> HM: sure, you'd have to — but you don't reveal it until the business is up and running.
 342 2013-02-24 02:40:13 CodeShark has joined
 343 2013-02-24 02:40:36 <muhoo> i think the business plan of trying to be secretive around a bunch of people who are experts at crypto is flawed
 344 2013-02-24 02:42:19 <HM> gmaxwell: i was thinking you could use the vanitygen algorithm to basically produce better brainwallets.
 345 2013-02-24 02:42:46 <gmaxwell> 'algorithim'
 346 2013-02-24 02:42:51 <gmaxwell> 'better brainwallets'
 347 2013-02-24 02:42:54 <gmaxwell> you're weird.
 348 2013-02-24 02:43:07 <HM> lol how so
 349 2013-02-24 02:44:35 <HM> if you use the passphrase 'hmisweird' at brainwallet.org you get 1Ce3daxhv51zZLNN3VydcqitMV2zmoDWt3
 350 2013-02-24 02:44:56 grau has joined
 351 2013-02-24 02:45:07 <Luke-Jr> HM: brainwallets are insecure period
 352 2013-02-24 02:45:08 <HM> but why not randomly select a prefix and seed the PRNG in vanity gen with a hash of 'hmisweird'
 353 2013-02-24 02:45:16 <HM> then just keep going until you get a hit
 354 2013-02-24 02:45:24 <HM> Luke-Jr: i know
 355 2013-02-24 02:45:35 <Luke-Jr> HM: that doesn't improve security..
 356 2013-02-24 02:45:56 <HM> It reduces the potential for an *untargeted* dictionary attack
 357 2013-02-24 02:46:07 <HM> because the prefix effectively becomes a random salt
 358 2013-02-24 02:46:57 <HM> even if you knew 'hmisweird' you wouldn't get the keypair without knowing my address and targetting me specifically
 359 2013-02-24 02:47:33 <petertodd> HM: look, this is the thing about brainwallets. Fundamentally people seem to reliably be able to memorize a small about of information, lets say 32bits right?
 360 2013-02-24 02:47:48 <HM> sure
 361 2013-02-24 02:47:56 <petertodd> *Any* key strengthing algorithm will do n amount of work, and the strength in terms of bits is log2(n)
 362 2013-02-24 02:48:12 <petertodd> However, the attacker has access to dedicated GPU's, dedicated hardware, all sorts of crazy shit.
 363 2013-02-24 02:48:22 <muhoo> gmaxwell: is this yours? https://github.com/samr7/vanitygen
 364 2013-02-24 02:48:24 <petertodd> So for them, to do n work, is *way* easier than for you to.
 365 2013-02-24 02:48:40 <HM> but any *popular implementation* will use a specific number of rounds and a static salt
 366 2013-02-24 02:48:45 <ymirhotfoot> http://en.wikipedia.org/wiki/Between_Silk_and_Cyanide:_A_Codemaker%27s_Story_1941-1945 [page was last modified on 29 January 2013 at 17:33] I think discusses something close to these questions.
 367 2013-02-24 02:48:54 <gmaxwell> muhoo: nope, I never had much interest in vanity generation.
 368 2013-02-24 02:48:55 <petertodd> You might manage, say, 32bits of strengthening if you are lucky. Now you're just up to 64-bits, and maybe less than that.
 369 2013-02-24 02:49:04 <petertodd> 64-bits can be brute-forced sadly.
 370 2013-02-24 02:49:11 <HM> so a dictionary attack can still work and you can scan the entire blockchain looking for chumps using a particular implementation
 371 2013-02-24 02:49:17 <gmaxwell> HM: the sipa seed strenghtener does that in a better way.
 372 2013-02-24 02:49:32 grau has quit (Ping timeout: 264 seconds)
 373 2013-02-24 02:49:39 <HM> gmaxwell: do tell :)
 374 2013-02-24 02:49:41 <petertodd> If you want do do anything remotely safe re: brain wallets, use a known, semi-private key, with 128-bits of security, and add the wallet password to that. But that's basically just password protected wallets...
 375 2013-02-24 02:50:00 <gmaxwell> petertodd: with bad password rotation ability.
 376 2013-02-24 02:50:07 <petertodd> Yup
 377 2013-02-24 02:50:16 <HM> petertodd: indeed, but the point of a brainwallet is to be memorable
 378 2013-02-24 02:50:31 <petertodd> If you could get the 128bits from the person publicly, it'd almost work, like 128-bits of yes know questions, but really, good luck...
 379 2013-02-24 02:50:47 <petertodd> (gavin's suggestion of drivers license is the best I've ever seen, but even it's problematic)
 380 2013-02-24 02:50:47 <HM> memorable + encrypted copy of my wallet isn't just 'memorable'
 381 2013-02-24 02:52:03 <petertodd> I'm happy to use a brainwallet myself, but I know my password is 128bits worth, because I generated it randomly... but I'm a weirdo.
 382 2013-02-24 02:52:04 <gmaxwell> petertodd: only stops precomputation, doesn't actually give you entropy, alas. Also— prompting people for things like name/email/etc make them think the system is not private, or—worse— that password recovery might work.
 383 2013-02-24 02:52:29 <CodeShark> you can always make the effort to memorize a truly random string of numbers :)
 384 2013-02-24 02:52:35 <gmaxwell> petertodd: the risk of that one is that you're probably underestimating your memory. Hopefully you have a paperbackup and all is good.
 385 2013-02-24 02:52:37 <petertodd> gmaxwell: Yeah, you get crazy attacks like "lets grab the copy of the drivers license database for the states"
 386 2013-02-24 02:53:10 <gmaxwell> petertodd: in florida the drivers license number is a simple function of name, gender, and dob.. so you can just guess valid ones there.
 387 2013-02-24 02:53:14 <petertodd> gmaxwell: Nah, I generated this stuff for non-Bitcoin reasons - I've known about the entropy problem with passwords for a long time...
 388 2013-02-24 02:53:29 <petertodd> gmaxwell: That attack too...
 389 2013-02-24 02:53:33 freewil has quit (Quit: Leaving)
 390 2013-02-24 02:53:41 <HM> gmaxwell: passport numbers in the UK encode your date of birth and other details, the remaining bit is sequentially issued
 391 2013-02-24 02:53:52 <petertodd> gmaxwell: Of course, that means I'm vulnerable to keyloggers and the like.
 392 2013-02-24 02:53:54 <HM> but then it's not really sensitive information
 393 2013-02-24 02:54:46 <HM> the NFC chip in UK passports requires your DOB, date of passport issue, and passport number to access cryptographically (one assumes) and contains your photo
 394 2013-02-24 02:55:19 <HM> which is odd because at airports they don't type that stuff in
 395 2013-02-24 02:55:24 <petertodd> Those NFC chip implementations are really clever: they're basically about preventing remote access without opening the password. Unfortunately they don't prevent targeted IED's...
 396 2013-02-24 02:55:33 <petertodd> It's in the barcode.
 397 2013-02-24 02:55:40 <HM> ah of course
 398 2013-02-24 02:56:12 <HM> presumably they have a digital signiture to prevent fraud
 399 2013-02-24 02:56:26 <HM> signature
 400 2013-02-24 02:56:36 <petertodd> Good question - I dunno. Given it's a physical thing quite possibly no.
 401 2013-02-24 02:56:47 <petertodd> (which leaves the "insert a second chip" attack)
 402 2013-02-24 02:57:07 <HM> well i think the NFC chip is there because physical fraud is too easy
 403 2013-02-24 02:57:22 <HM> so you have to break both now
 404 2013-02-24 02:57:33 <petertodd> Yes, but this is crypto quite possibly designed by non-technical people...
 405 2013-02-24 02:57:39 <petertodd> I wouldn't make assumptions.
 406 2013-02-24 02:58:13 <CodeShark> much of the "security" stuff that governments do is just for show
 407 2013-02-24 02:58:17 <HM> Oyster card for the London underground was broken
 408 2013-02-24 02:58:42 <petertodd> This is why Bitcoin is so crazy: fuck up the security and you have real problems.
 409 2013-02-24 02:58:56 <petertodd> It's not just for show like in the real world.
 410 2013-02-24 02:59:00 <HM> nah
 411 2013-02-24 02:59:28 <HM> if you have a way to prove exactly *when* it was broken you can always agree on the fix and carry everything over
 412 2013-02-24 03:00:01 <HM> that way you only screw a few 100,000 people instead of a 100 million :P
 413 2013-02-24 03:00:06 <gmaxwell> HM: lol and undo potentially months of transactions?
 414 2013-02-24 03:00:07 ymirhotfoot has quit (Remote host closed the connection)
 415 2013-02-24 03:00:28 <HM> it's the same with cash
 416 2013-02-24 03:00:29 <muhoo> iirc the brainwallet impl i saw (in js?) takes the password and sha256's it a few times before generating the private key
 417 2013-02-24 03:00:38 <HM> fraudulant notes can be removed from circulation but the damage is done
 418 2013-02-24 03:00:55 <gmaxwell> muhoo: yes, and thats a horrible idea.
 419 2013-02-24 03:01:12 fishfish has quit (Quit: Leaving...)
 420 2013-02-24 03:01:15 <HM> are all 256 bit values even valid private keys?
 421 2013-02-24 03:01:20 <gmaxwell> No.
 422 2013-02-24 03:01:24 <CodeShark> well, sorta
 423 2013-02-24 03:01:24 <HM> well there you go lol
 424 2013-02-24 03:01:31 <CodeShark> mod order G
 425 2013-02-24 03:01:47 <gmaxwell> well, 0 isn't either.
 426 2013-02-24 03:01:47 <CodeShark> order G is very nearly 2^256
 427 2013-02-24 03:01:53 <HM> I read something about 'twists' in elliptical curves, to do with this i think
 428 2013-02-24 03:01:54 <muhoo> gmaxwell: still open to dictionary attacks against all addresses in all tx's in the blockchain?
 429 2013-02-24 03:02:10 <petertodd> I suspect people are already doing that...
 430 2013-02-24 03:02:14 freewil has joined
 431 2013-02-24 03:02:20 <CodeShark> if you pick a random 256-bit number, the overwhelming probability is that it will be a valid private key
 432 2013-02-24 03:02:22 <petertodd> Just maybe not on a huge scale.
 433 2013-02-24 03:02:28 <gmaxwell> muhoo: yea, an attacker gets an enormous precomputation gain... with 1 unit of work he attacks all past (and with some storage— future) users of that scheme.
 434 2013-02-24 03:03:09 <petertodd> muhoo: You gotta realize, the bitcoin elite all want people to stop using brainwallets to discourage those attackers so we can keep getting away with them.
 435 2013-02-24 03:03:30 <muhoo> "getting away with them"??
 436 2013-02-24 03:03:37 <HM> better be safe and use double md5
 437 2013-02-24 03:03:42 <HM> stay under the radar ;)
 438 2013-02-24 03:04:05 <muhoo> petertodd: that's a curious turn of phrase
 439 2013-02-24 03:04:20 * HM wonders how many times you have to hash 'password' with md5 before you don't get a google hit
 440 2013-02-24 03:04:33 <muhoo> what exactly are "we" trying to "get away" with?
 441 2013-02-24 03:04:33 <CodeShark> actually, you can even choose a private key larger than order G - but (order G + 1) is the same private key as 1
 442 2013-02-24 03:04:38 <petertodd> HM: all bet you once...
 443 2013-02-24 03:04:42 <Luke-Jr> HM: hm, good question
 444 2013-02-24 03:04:46 <petertodd> muhoo: I mean, so the elite can keep using them.
 445 2013-02-24 03:04:54 <muhoo> using what, brainwallets?
 446 2013-02-24 03:04:55 <CodeShark> the only two 256-bit numbers that you really cannot use as a private key are 0 and order G
 447 2013-02-24 03:05:11 <petertodd> HM: *I'll bet you once...
 448 2013-02-24 03:05:20 <CodeShark> but you probably don't want to use a small value either :)
 449 2013-02-24 03:05:39 agricocb has joined
 450 2013-02-24 03:05:44 <petertodd> CodeShark: heh, I had like a bitcoin or something sitting in seckey 1 for ages
 451 2013-02-24 03:05:51 <muhoo> that's kind of silly. attackers gonna attack.
 452 2013-02-24 03:05:52 <CodeShark> haha
 453 2013-02-24 03:05:57 <petertodd> The uncompressed version was taken long ago, not the compressed...
 454 2013-02-24 03:05:57 <gmaxwell> petertodd: nah, it's important to agressively discourage their use so that when people go ahead and use them anyways and get hundreds of thousands of dollars worth of bitcoin stolen everyone will blame them for using brainwallets rather than blaming bitcoin and undermining confidence in it.
 455 2013-02-24 03:06:11 <gmaxwell> (and maybe even I actually care about people getting ripped of…)
 456 2013-02-24 03:06:24 <petertodd> gmaxwell: sheesh, you ruin all our fun...
 457 2013-02-24 03:06:25 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Ping timeout: 276 seconds)
 458 2013-02-24 03:06:27 <petertodd> :P
 459 2013-02-24 03:06:43 <petertodd> gmaxwell: Yeah, in general, anything like that *will* result in bad PR.
 460 2013-02-24 03:07:02 <petertodd> gmaxwell: ...remind me to not write a GUI for trustbits...
 461 2013-02-24 03:07:08 <HM> there are still google hits for md5('password')^5
 462 2013-02-24 03:07:12 <HM> i can't be bothered to go more
 463 2013-02-24 03:07:28 <gmaxwell> less bad if everyone will mock them.  It's so stupid. You do something 'dumb' that _everyone_ does and maybe you don't even have a choice to avoid, but when you get burned it was your fault because it was 'dumb'.
 464 2013-02-24 03:07:39 licnep has joined
 465 2013-02-24 03:07:52 <petertodd> Yes, if we can win the meme war there...
 466 2013-02-24 03:08:03 <muhoo> a friend got ripped off for a huge amount by storing large amounts of BTC in a windoze bitcoin-qt machine that he left running 24/7
 467 2013-02-24 03:08:12 <gmaxwell> While I think that effect of blaming the victim is unfortunate and wrong, ... I don't hesitate to use it to avoid panic undermining trust in bitcoin.
 468 2013-02-24 03:08:23 <petertodd> Would be useful to do some fake stories posing as "fuck, I lost all my BTC because I was a brainwallet dumb-ass" until it's well accepted it's an incredibly stupid thing to do.
 469 2013-02-24 03:08:34 <gmaxwell> petertodd: there are already real stories of it.
 470 2013-02-24 03:08:42 <petertodd> gmaxwell: Where?
 471 2013-02-24 03:08:53 <gmaxwell> though people seem to have 20/20 hindsight on how secure a given string is.
 472 2013-02-24 03:08:53 <petertodd> gmaxwell: other than the tests...
 473 2013-02-24 03:09:05 <petertodd> hunter2
 474 2013-02-24 03:09:07 <muhoo> so i told him to move his shit to a cold-storage address, and he went diving straight for brainwallets.
 475 2013-02-24 03:09:25 <petertodd> muhoo: sigh...
 476 2013-02-24 03:09:25 * jaakkos thanks media for telling how bitcoin has repeatedly been hacked, perhaps makes me more of an early adopter
 477 2013-02-24 03:10:13 <gmaxwell> muhoo: yea, there is a mystical attraction with that.. really dangerous. oh well.
 478 2013-02-24 03:10:22 <muhoo> convenience, really.
 479 2013-02-24 03:10:30 <muhoo> not mysticism, laziness, i expect.
 480 2013-02-24 03:10:56 <gmaxwell> muhoo: a brainwallet tool could just as easily give you 12 words to write down. even less work then remembering something good.
 481 2013-02-24 03:11:03 <muhoo> people will spend US$2 to get money out of the ATM on this side of the street instead of walking across the street to their own bank's ATM
 482 2013-02-24 03:11:18 <petertodd> Even regardless of the security of the wallets themselves, the software is probably crap too given few smart people use it.
 483 2013-02-24 03:11:51 <muhoo> gmaxwell: so, with some # bits of entropy, a brainwallet isn't a honeypot?
 484 2013-02-24 03:11:51 <petertodd> I have a suspicion that bitaddress.org doesn't always return the same privkeys for a given brainwallet password...
 485 2013-02-24 03:12:03 ymirhotfoot has joined
 486 2013-02-24 03:12:26 <petertodd> I put some money in some obvious words to test, wrote down the addrs, and on one of them I didn't get the same address the next time.
 487 2013-02-24 03:12:41 <petertodd> Maybe typo? Maybe bug? Who knows.
 488 2013-02-24 03:12:43 <HM> i had this debate with someone regarding Mega file storage service
 489 2013-02-24 03:12:53 <HM> the crypto is clientside but the code is served from server side
 490 2013-02-24 03:13:00 <HM> how is that ever secure?
 491 2013-02-24 03:13:10 <HM> it's not like it's signed and cannot change after you've audited it
 492 2013-02-24 03:13:12 <petertodd> HM: mega is not about security, it's about plausible deniability
 493 2013-02-24 03:13:24 <HM> they haven't got that either
 494 2013-02-24 03:13:35 <gmaxwell> muhoo: sure— its the same thing as a regular private key at some point. The question is 'entropy' if you enter in "0qww194w!
 495 2013-02-24 03:13:35 <HM> i mean kinda not really
 496 2013-02-24 03:13:40 <HM> it's iffy at best
 497 2013-02-24 03:13:43 <gmaxwell> " does that have high entropy? no way to tell.
 498 2013-02-24 03:13:54 <gmaxwell> But a machine generated key of sufficient length is fine.
 499 2013-02-24 03:14:00 <petertodd> Yes they do, until they are forced to screw with their code server-side, and that will make it obvious to the word.
 500 2013-02-24 03:14:03 <petertodd> *world
 501 2013-02-24 03:14:11 <gmaxwell> 12 words is enough to get you 128 bits of entropy, at which point the security of ECDSA starts becoming the limiting factor.
 502 2013-02-24 03:14:35 <muhoo> gmaxwell: thanks, that makes a lot of sense.
 503 2013-02-24 03:15:29 <muhoo> so, a less hackable brainwallet tool would either generate the words, or require the user to enter 12 of their own words (and check against duplication, etc)?
 504 2013-02-24 03:15:44 <HM> another problem is the dictionary
 505 2013-02-24 03:15:56 <HM> if the brianwallet site uses one and changes it or loses it, you're boned
 506 2013-02-24 03:16:09 <gmaxwell> muhoo: nah, if the user enters their own they'll pick from a much lower entropy space than they think they are.
 507 2013-02-24 03:16:21 <gmaxwell> 12 words is sufficient if the machine is picking.
 508 2013-02-24 03:16:35 * muhoo wonders how many passwords out ther now are "correct horse battery staple"
 509 2013-02-24 03:16:40 <gmaxwell> because the machine can pick uniformly from a dictionary.
 510 2013-02-24 03:16:52 <HM> users will favour words like "secure" and "monkey" over supercalifragilisticexpialidociousantidisestablishmentarianism
 511 2013-02-24 03:16:58 <gmaxwell> ::sigh:: that xkcd thing has caused more harm than good...
 512 2013-02-24 03:17:19 PhantomSpark has joined
 513 2013-02-24 03:17:25 PhantomSpark has joined
 514 2013-02-24 03:17:25 <gmaxwell> (esp since it gives an example where an attacker can test 1000 per second instead of a billion per second.
 515 2013-02-24 03:17:28 <gmaxwell> )
 516 2013-02-24 03:17:50 <HM> just write your passwords down
 517 2013-02-24 03:17:56 <HM> or use a keymanager
 518 2013-02-24 03:18:03 <gmaxwell> HM: yea, or god knows what else. It's remarkable how powerful sufficiently advanced statistical models are.
 519 2013-02-24 03:18:25 <petertodd> gmaxwell: the amount of grief over hash functions really bothers me - the right solution is to make a separate box with a stupidly locked down 'net connection that does nothing more than store passwords, and give them back with a fixed delay
 520 2013-02-24 03:18:42 sgornick has quit (Quit: Ex-Chat)
 521 2013-02-24 03:18:52 <HM> so a slow clock driving a PRNG
 522 2013-02-24 03:18:55 <petertodd> gmaxwell: You know, you can even guy hardware-assisted password hashiing accellerators now, for enterprise usage.
 523 2013-02-24 03:18:55 <gmaxwell> sure... machine generate, write it down— thats fine.  One problem is the decades of "OMG NEVER WRITE A PASSWORD DOWN" advice, that makes sense in some green-screen office enviroment where the attacker is the nosy guy in the next cube, and a lost password can be recovered for you by IT.... it's less good advice for bitcoin keys.
 524 2013-02-24 03:19:36 <gmaxwell> petertodd: you can actually use a yubikey to secure passwords. pretty cool.
 525 2013-02-24 03:19:41 <HM> what i hate is websites than say "your password must be between 6 and 8 characters and include at least 1 number, 1 uppercase letter and 1 symbol"
 526 2013-02-24 03:19:52 * HM facepalm
 527 2013-02-24 03:20:01 <gmaxwell> yubikey can run in hmac mode.. load it with an unknown hmac key, and now its a secure 'uncopyable' password hashing oracle.
 528 2013-02-24 03:20:04 <petertodd> gmaxwell: oh, they're hsm?
 529 2013-02-24 03:20:13 <petertodd> gmaxwell: Oh, nice!
 530 2013-02-24 03:20:20 <HM> that's pretty cool
 531 2013-02-24 03:20:21 <gmaxwell> petertodd: insanely cheap, and pretty limited, usb hsms. Yes.
 532 2013-02-24 03:20:35 <petertodd> gmaxwell: I've got they're little touch-based usb thing.
 533 2013-02-24 03:20:56 <gmaxwell> yea, but they can run in a mode where no touch is required.. just acting as a little hmac engine with an embedded secret.
 534 2013-02-24 03:20:57 <petertodd> gmaxwell: I use it to ensure that password-only logins to my computer can only happen when someone is physically there.
 535 2013-02-24 03:21:18 <petertodd> Do you know if that mode is supported by pam yet?
 536 2013-02-24 03:21:24 <gmaxwell> no clue.
 537 2013-02-24 03:21:36 <petertodd> Touch-mode is a bit buggy, but otherwise cool.
 538 2013-02-24 03:21:47 <jaakkos> what if the thing breaks...
 539 2013-02-24 03:21:51 <gmaxwell> it does require more explicit support than just the standard hid emulation
 540 2013-02-24 03:22:11 <petertodd> jaakkos: keep a backup or somesuch
 541 2013-02-24 03:22:13 <HM> jaakkos: you restore your key from your pastebin backup :P
 542 2013-02-24 03:22:21 <HM> stored in your bookmarks
 543 2013-02-24 03:22:29 <gmaxwell> jaakkos: ideally what you'd do is keep the hmac key offline someplace, then load it into the yubi.. and plug the yubi into your webserver or whatever.. if it breaks, you just make another.
 544 2013-02-24 03:22:39 <jaakkos> yeah
 545 2013-02-24 03:22:54 <gmaxwell> but that means if someone compromises your webserver the worst they can do is use the yubi as an oracle until you catch them.
 546 2013-02-24 03:23:17 <gmaxwell> Though the regular yubi is pretty slow, for a popular website you'd need to use a faster hsm.. (yubi makes one, dunno the price)
 547 2013-02-24 03:23:18 <jaakkos> well of course the backup should be encrypted
 548 2013-02-24 03:23:24 <HM> oooo NFC Yubikey
 549 2013-02-24 03:23:34 <jaakkos> though the encryption won't be as strong as the encryption provided by the key, as discussed.
 550 2013-02-24 03:24:08 <jaakkos> (if a brain key is used, that is)
 551 2013-02-24 03:24:08 <gmaxwell> jaakkos: well the backup should be offline— so in one way its much stronger.
 552 2013-02-24 03:27:49 ymirhotfoot has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 553 2013-02-24 03:28:41 PhantomSpark has quit (Read error: Connection reset by peer)
 554 2013-02-24 03:30:17 <HM> the OATH functions are ridiculously simple
 555 2013-02-24 03:37:01 Scrat has quit (Ping timeout: 252 seconds)
 556 2013-02-24 03:39:07 Scrat_f has joined
 557 2013-02-24 03:40:34 Goonie has quit (Ping timeout: 252 seconds)
 558 2013-02-24 03:46:07 Bwild has quit (Ping timeout: 240 seconds)
 559 2013-02-24 03:47:42 Bwild has joined
 560 2013-02-24 03:51:15 fiesh has quit (Ping timeout: 260 seconds)
 561 2013-02-24 03:51:23 profmac has quit (Quit: Page closed)
 562 2013-02-24 03:56:49 fiesh has joined
 563 2013-02-24 04:00:24 paraipan has joined
 564 2013-02-24 04:01:10 alexwaters1 has joined
 565 2013-02-24 04:02:53 <muhoo> holy crap. just for grins, in 15 seconds i found the pk of someone who used a shitty password brain wallet.
 566 2013-02-24 04:02:54 alexwaters11 has quit (Ping timeout: 246 seconds)
 567 2013-02-24 04:03:23 <muhoo> no balance on it, hopefully it was just a dev playing around
 568 2013-02-24 04:04:01 <gmaxwell> or it was already emptied.
 569 2013-02-24 04:04:10 paraipan has quit (Client Quit)
 570 2013-02-24 04:04:34 paraipan has joined
 571 2013-02-24 04:05:30 <muhoo> good point. well it wasn't much. the maximum balance looks like 2 bitcents. still, wow.
 572 2013-02-24 04:05:53 <petertodd> might have been one of my tests...
 573 2013-02-24 04:08:16 <jaakkos> muhoo: dictionary?
 574 2013-02-24 04:09:09 <phantomcircuit> muhoo, there are a lot of terrible brainwallets
 575 2013-02-24 04:09:33 ProfMac has joined
 576 2013-02-24 04:09:34 <gmaxwell> I admit, one of the reasons I hate on brainwallets is because the creator of brainwallet.org started off his illustrious efforts by bruteforcing passphrase key, and complaining in #bitcoin he only found (and took the coin from) a couple.
 577 2013-02-24 04:09:37 <muhoo> jaakkos: no, just something obvious i figured i'd try. not "testing" but not much better either
 578 2013-02-24 04:09:50 <jaakkos> scavenge feast \o/
 579 2013-02-24 04:10:18 <gmaxwell> So, an uncharitable interpertation is that the site was created in order to resolve the problem of there not being enough victims.
 580 2013-02-24 04:10:29 ThomasV has joined
 581 2013-02-24 04:10:33 <muhoo> that's deeply suspicious
 582 2013-02-24 04:11:11 <gmaxwell> muhoo: well, evil is less likely than stupidity in any case where the latter is also an acceptable explination. :)
 583 2013-02-24 04:11:17 paraipan has quit (Quit: Saliendo)
 584 2013-02-24 04:11:22 <muhoo> it's so tempting though. i feel dirty for even trying one. it'd be so trivial to keep going, but there is NFW i'm going down that dark hole.
 585 2013-02-24 04:11:29 BTC_Bear has quit (Ping timeout: 245 seconds)
 586 2013-02-24 04:11:35 <muhoo> bad juju
 587 2013-02-24 04:11:40 <gmaxwell> muhoo: yea, what do you do if you find one with 10k btc on it? It's not like you can warn the owner.
 588 2013-02-24 04:11:52 <ProfMac> nah, stupidity is a strong force.
 589 2013-02-24 04:11:54 <petertodd> it is like you fire up tor...
 590 2013-02-24 04:12:00 <muhoo> that was exactly my next question. it's anonymous, there's no way to do the right tihng
 591 2013-02-24 04:12:05 <muhoo> thing
 592 2013-02-24 04:12:16 <gmaxwell> There is an argument that sending those funds to a charity would be the most ethical thing to do. :-/  better it go someplace honest than to a theif.
 593 2013-02-24 04:12:33 <gmaxwell> then again, that they haven't been stolen yet is evidence that they won't be.
 594 2013-02-24 04:12:34 <petertodd> heh, create a huge fee tx with it...
 595 2013-02-24 04:12:36 <muhoo> which'd be to send an email, saying "hey, asshole, you left your wallet on the cafeteria table!"
 596 2013-02-24 04:12:54 <petertodd> or fidelity bond, so it looks like they meant it
 597 2013-02-24 04:12:55 <jaakkos> i can't believe there are not already hordes of people doing that
 598 2013-02-24 04:13:06 <petertodd> jaakkos: probably not enough victims
 599 2013-02-24 04:13:33 <gmaxwell> jaakkos: you'd be surprised, a lot of outright vulnerable things just don't get exploited.
 600 2013-02-24 04:13:55 <ProfMac> with PGP keys, it is possible to revoke a key.  Could a bitcoin transaction be "revoked" in the case of stolen funds?  I know that opens up a hornet's next, but I think it needs to be asked.  Also, I am enjoying a few glasses of wine. :-)
 601 2013-02-24 04:13:58 <muhoo> well let me do this.
 602 2013-02-24 04:14:05 <gmaxwell> Also, if someone has been getting retired mining fpgas and building big brainwallet rainbowtables... there is some amount of attack delay that is optimally rational: steal too early and you get fewer funds.
 603 2013-02-24 04:14:09 <petertodd> gmaxwell: well, there is that too...
 604 2013-02-24 04:14:09 <jgarzik> ProfMac: no
 605 2013-02-24 04:14:21 <muhoo> i'll just warn here that anyone using "correct horse battery staple" as his/her brainwallet password is a stupid douchebag.
 606 2013-02-24 04:14:39 <ProfMac> jgarzik, LOL.  That's pretty succinct.
 607 2013-02-24 04:14:42 <petertodd> I use "correct horse battery staple2" myself
 608 2013-02-24 04:14:47 <gmaxwell> muhoo: or they didn't click in the webpage.
 609 2013-02-24 04:14:58 <muhoo> which webpage?
 610 2013-02-24 04:15:02 <Luke-Jr> lol
 611 2013-02-24 04:15:18 <gmaxwell> muhoo: brainwallet.org, that defaults to that string.
 612 2013-02-24 04:15:33 <muhoo> hahaha
 613 2013-02-24 04:17:08 <petertodd> brainwallet.org is bad enough re: fees
 614 2013-02-24 04:17:12 <muhoo> i was using bitaddress.org
 615 2013-02-24 04:17:14 <petertodd> way too easy to screw that up
 616 2013-02-24 04:19:14 robocoin has quit (Quit: ~_~;)
 617 2013-02-24 04:24:42 rbecker is now known as RBecker
 618 2013-02-24 04:38:44 <gmaxwell> petertodd: reference client is no better wrt that.
 619 2013-02-24 04:39:55 <petertodd> gmaxwell: the reference client is an API, I expect it to have a shoot your foot feature...
 620 2013-02-24 04:42:34 <gmaxwell> it's also the cli client and power user tool, which you and I and everyone else in this room uses as an end user too. :)
 621 2013-02-24 04:43:47 <gmaxwell> (also, because the JSON stuff looks/smells/tastes like floats, its quite easy to get your values slightly wrong...)
 622 2013-02-24 04:44:29 <petertodd> yeah, well, the fact that it isn't just a utxo database + script engine + p2p was a mistake
 623 2013-02-24 04:44:38 <petertodd> I mean, heck, doesn't need need the p2p strictly speaking
 624 2013-02-24 04:45:17 <gmaxwell> well, at some point there needs to be software to use. It's not like making it all seperate makes it much easier to write. :)
 625 2013-02-24 04:45:28 <Luke-Jr> gmaxwell: it does make it easier to maintain
 626 2013-02-24 04:45:42 <gmaxwell> (and I mean power user software too— being able to exactly construct txn is very useful)
 627 2013-02-24 04:47:02 <petertodd>  well, the main thing to do is make some solid tx review software
 628 2013-02-24 04:47:11 <petertodd> integrated with the payment protocol and other stuff
 629 2013-02-24 04:47:22 ThomasV has quit (Quit: Quitte)
 630 2013-02-24 04:47:59 <petertodd> but I should stop whining and write that :P
 631 2013-02-24 04:48:54 ThomasV has joined
 632 2013-02-24 04:59:21 [7] has quit (Disconnected by services)
 633 2013-02-24 04:59:27 TheSeven has joined
 634 2013-02-24 05:03:55 copumpkin has quit (Ping timeout: 252 seconds)
 635 2013-02-24 05:04:30 copumpkin has joined
 636 2013-02-24 05:10:17 <muhoo> wasn't someone writing something that'd let you create custom tx's that were multi-signed, like in the "i taint rich" thread, without accidentally creating 1BTC fees or some such error?
 637 2013-02-24 05:14:32 ymirhotfoot has joined
 638 2013-02-24 05:16:58 ProfMac has quit (Quit: Page closed)
 639 2013-02-24 05:17:07 HM has quit (Ping timeout: 252 seconds)
 640 2013-02-24 05:18:16 HM has joined
 641 2013-02-24 05:23:35 FredEE has joined
 642 2013-02-24 05:26:40 D34TH has quit (Quit: Leaving)
 643 2013-02-24 05:31:46 ymirhotfoot has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 644 2013-02-24 05:52:20 <jgarzik> muhoo: I had talked about doing such
 645 2013-02-24 05:52:25 <jgarzik> just talk ATM
 646 2013-02-24 05:53:04 * jgarzik wants a tool for "weird transactions" -- handling the user interface portion -- that would interface with bitcoind via RPC raw API for the "real work".
 647 2013-02-24 05:53:52 <jgarzik> coin control is an easy example, but there are many possibilities like participating in multi-sig transactions
 648 2013-02-24 05:54:23 <jgarzik> in particular, multi-step transactions that linger until fully signed would be made more readily accessible with such a tool
 649 2013-02-24 06:00:01 HM has quit (Ping timeout: 252 seconds)
 650 2013-02-24 06:05:07 <Diablo-D3> https://code.google.com/p/fpga-x86-processor/
 651 2013-02-24 06:15:44 toffoo has quit ()
 652 2013-02-24 06:21:03 grau has joined
 653 2013-02-24 06:22:05 PhantomSpark has quit (3!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Ping timeout: 276 seconds)
 654 2013-02-24 06:22:05 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Ping timeout: 276 seconds)
 655 2013-02-24 06:24:35 grau has quit (Read error: Operation timed out)
 656 2013-02-24 06:28:20 snakie has quit (Remote host closed the connection)
 657 2013-02-24 06:29:11 snakie has joined
 658 2013-02-24 06:35:38 <Luke-Jr> Diablo-D3: WHY x86? :/
 659 2013-02-24 06:38:07 pooler has quit (Remote host closed the connection)
 660 2013-02-24 06:39:12 <Diablo-D3> Luke-Jr: yeah, I wish he had done x86-64
 661 2013-02-24 06:39:30 eitan has joined
 662 2013-02-24 06:39:56 <Luke-Jr> obviously it should be MIPS
 663 2013-02-24 06:40:27 <Diablo-D3> eh, mips isnt the fix you think it is
 664 2013-02-24 06:40:31 <eitan> are there ways to speed up elliptic curve group operations on the secp2k1 curve?
 665 2013-02-24 06:41:01 <Diablo-D3> Luke-Jr: not only that, there already is several foss mips cores
 666 2013-02-24 06:41:07 <Luke-Jr> so?
 667 2013-02-24 06:42:00 <Diablo-D3> some are on fpga.
 668 2013-02-24 06:43:17 <eitan> sorry...meant secp256k1 curve, the one used for ECDSA in the bitcoin protocol???
 669 2013-02-24 06:43:57 <Luke-Jr> eitan: sipa has a pullreqeust with some optimizations, but it isn't merged due to lack of a proper security expert
 670 2013-02-24 06:45:01 <eitan> Luke-Jr: but just using naive formulae for point doubling or point adding works fine? just trying to see if i have a problem in my code or if it's normally balls-slow
 671 2013-02-24 06:45:55 <Luke-Jr> I'm not a cryptographer, sorry.
 672 2013-02-24 06:46:33 <eitan> that's ok :-) thanks
 673 2013-02-24 06:48:00 [\\\] has quit (Remote host closed the connection)
 674 2013-02-24 06:49:47 [\\\] has joined
 675 2013-02-24 06:59:28 ProfMac has joined
 676 2013-02-24 07:09:51 ThomasV has quit (Quit: Quitte)
 677 2013-02-24 07:12:17 [\\\] has quit (Remote host closed the connection)
 678 2013-02-24 07:14:03 [\\\] has joined
 679 2013-02-24 07:24:31 brocktice has quit (Ping timeout: 246 seconds)
 680 2013-02-24 07:26:58 grau has joined
 681 2013-02-24 07:31:40 PhantomSpark has joined
 682 2013-02-24 07:31:42 PhantomSpark has joined
 683 2013-02-24 07:31:48 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Client Quit)
 684 2013-02-24 08:12:14 Mrcheesenips has quit (Read error: Connection reset by peer)
 685 2013-02-24 08:12:37 Mrcheesenips has joined
 686 2013-02-24 08:23:59 FredEE has quit (Quit: FredEE)
 687 2013-02-24 08:27:27 idstam has joined
 688 2013-02-24 08:41:06 eitan has quit (Ping timeout: 245 seconds)
 689 2013-02-24 08:41:49 JDuke128 has joined
 690 2013-02-24 08:43:08 <CodeShark> eitan, if you want some tips on optimization of secp256k1, it's actually something I've been looking into lately
 691 2013-02-24 08:44:39 <CodeShark> for signing, using naive formulae on a fast CPU is probably good enough from a performance standpoint - for verifying the block chain, no way :)
 692 2013-02-24 08:45:11 <CodeShark> you certainly want to use jacobian coordinates, NAF, and an optimized bignum library
 693 2013-02-24 08:45:25 <CodeShark> and it also helps tremendously if you precompute tables
 694 2013-02-24 08:48:45 <CodeShark> multiprecision arithmetic is a real artform :)
 695 2013-02-24 08:52:20 mappum has quit (Ping timeout: 245 seconds)
 696 2013-02-24 09:06:09 Scrat_f has quit (Remote host closed the connection)
 697 2013-02-24 09:10:14 kirill42 has joined
 698 2013-02-24 09:11:25 Goonie has joined
 699 2013-02-24 09:11:36 BTC_Bear has joined
 700 2013-02-24 09:12:48 BTCOxygen has joined
 701 2013-02-24 09:13:32 <BTC_Bear> What's the consensus, if any, on the amount of BTC lost to Attrition?  At what point, will action have to be taken? I believe the solution was to increase the placement.
 702 2013-02-24 09:25:08 justarandomguy has joined
 703 2013-02-24 09:26:17 <justarandomguy> Hey guys, I am looking for some basic help getting set up with programatically sending/receiving bitcoins
 704 2013-02-24 09:27:37 <CodeShark> what are you trying to do?
 705 2013-02-24 09:28:44 <justarandomguy> just create a small web app that will check for coins received and then send it.   basically recreating a smaller version of satoshi dice just for experience
 706 2013-02-24 09:29:00 kirill42 has quit (Ping timeout: 245 seconds)
 707 2013-02-24 09:29:26 <justarandomguy> i think I am supposed to be using bitcoind but I am not really sure on the how/why
 708 2013-02-24 09:29:36 <CodeShark> have you already checked out https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) ?
 709 2013-02-24 09:30:32 <justarandomguy> yes and when I use the php example I get an error about it not being able to open a stream.
 710 2013-02-24 09:30:50 <justarandomguy> I am not sure I have a server listening even though I do have bitcoin installed
 711 2013-02-24 09:30:58 <CodeShark> how did you install it?
 712 2013-02-24 09:31:24 <justarandomguy> errrr... im not sure.  I downloded from bitcoin org and ran it, i have the GUI version up right now
 713 2013-02-24 09:31:42 <CodeShark> ok - so for programmatic access, you're going to want a headless build
 714 2013-02-24 09:31:59 <CodeShark> what OS are you planning on using it on?
 715 2013-02-24 09:32:25 <justarandomguy> right now id just like to get it working on win7 with the intention to migrate to linux later
 716 2013-02-24 09:32:56 RBecker is now known as rbecker
 717 2013-02-24 09:33:12 <CodeShark> linux is by far the most supported OS
 718 2013-02-24 09:33:18 <Luke-Jr> justarandomguy: be more specific about your error messages please
 719 2013-02-24 09:33:59 <justarandomguy> id like to get linux going but all my dev stuff is on windows right now.  if i can start getting api calls going then I can migrate easy enough
 720 2013-02-24 09:35:14 <justarandomguy> two error messeges:   1) require_once(jsonRPCClient.php):failed to open stream.   No such file or directory in my php directory.  it does ask for pear which i did nto notice before
 721 2013-02-24 09:35:35 <CodeShark> how experienced are you with cURL?
 722 2013-02-24 09:35:47 <justarandomguy> and 2)  error: you must set rpcpassrod in the config file, which it is set
 723 2013-02-24 09:35:59 <justarandomguy> decent amount of experience
 724 2013-02-24 09:36:15 <justarandomguy> i do lots of scraping and have worked with mtgox api before
 725 2013-02-24 09:36:22 <CodeShark> if you can make cURL calls directly, I would recommend doing that over using jsonRPCClient.php
 726 2013-02-24 09:36:42 <justarandomguy> yeah I would like to I just was looking for a solution and trying examples.
 727 2013-02-24 09:36:44 <CodeShark> jsonRPCClient.php is a very thin, unnecessary wrapper that doesn't even handle errors correctly
 728 2013-02-24 09:37:05 <Luke-Jr> justarandomguy: did you install http://jsonrpcphp.org/ like the wiki says to?
 729 2013-02-24 09:37:32 <Luke-Jr> justarandomguy: for 2, check that the config file is where bitcoind is expecting it, or use the commandline option -rpcpassword=whatever
 730 2013-02-24 09:37:46 MagicalTux has quit (Excess Flood)
 731 2013-02-24 09:37:53 MT`AwAy has joined
 732 2013-02-24 09:38:16 MT`AwAy is now known as Guest57991
 733 2013-02-24 09:38:21 Guest57991 is now known as MagicalTux
 734 2013-02-24 09:38:23 <Luke-Jr> (though CodeShark's advice to just avoid JSON-RPC PHP may be best)
 735 2013-02-24 09:38:26 MagicalTux has quit (Changing host)
 736 2013-02-24 09:38:26 MagicalTux has joined
 737 2013-02-24 09:38:31 <Luke-Jr> MagicalTux: O.o
 738 2013-02-24 09:38:43 <justarandomguy> yeah ive installed it like I am supposed too.
 739 2013-02-24 09:38:59 <justarandomguy> how can i ensure that the server is listening for the call?
 740 2013-02-24 09:39:10 <CodeShark> justarandomguy: I just use stuff like this http://pastebin.com/dMnzjQg2
 741 2013-02-24 09:39:13 <Luke-Jr> if it says rpcpassword isn't set, then it didn't start
 742 2013-02-24 09:39:17 kirill42 has joined
 743 2013-02-24 09:39:22 <CodeShark> customize the CURPOPT
 744 2013-02-24 09:40:10 <justarandomguy> are you sending it to @127.0.0.1:8332?
 745 2013-02-24 09:40:23 <CodeShark> check the port
 746 2013-02-24 09:40:35 <CodeShark> make sure it agrees with the RPC port in your config file
 747 2013-02-24 09:40:43 <justarandomguy> kk
 748 2013-02-24 09:40:59 <Luke-Jr> CodeShark: not gonna do him any good if bitcoind isn't even starting..
 749 2013-02-24 09:41:24 <CodeShark> well, of course, Luke-Jr - but I thought he said he had already installed bitcoind (or bitcoin-qt)
 750 2013-02-24 09:41:30 <Luke-Jr> [09:17:38] <justarandomguy> and 2)  error: you must set rpcpassrod in the config file, which it is set
 751 2013-02-24 09:41:48 <Luke-Jr> that error = bitcoind isn't starting
 752 2013-02-24 09:42:14 <CodeShark> grab a template like https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
 753 2013-02-24 09:42:24 ovidiusoft has joined
 754 2013-02-24 09:42:32 <justarandomguy> yeah thats the template I am using
 755 2013-02-24 09:42:32 <CodeShark> stick it in your bitcoin datadir
 756 2013-02-24 09:42:51 <justarandomguy> i tried to start bitcoind but it said it was already started
 757 2013-02-24 09:43:08 <jouke> are you running the cliënt and script on the same computer?
 758 2013-02-24 09:43:09 <CodeShark> what happens if you type "bitcoind getinfo" at the command line?
 759 2013-02-24 09:43:09 <Luke-Jr> justarandomguy: Bitcoin-Qt and bitcoind cannot run at the same time
 760 2013-02-24 09:43:50 <justarandomguy> snap, i thought they could
 761 2013-02-24 09:44:05 <CodeShark> they can...but it takes some tweaking :)
 762 2013-02-24 09:44:11 <CodeShark> you probably don't want to do that, though
 763 2013-02-24 09:44:47 <Luke-Jr> CodeShark: not with the same wallet/blockchain ;p
 764 2013-02-24 09:45:16 <justarandomguy> okay so i closed my gui, and tried to start bitcoind  and now...
 765 2013-02-24 09:45:37 <justarandomguy> giving me the same error rpcpassword is not set
 766 2013-02-24 09:45:48 <Luke-Jr> so it's not finding your config file
 767 2013-02-24 09:45:51 <CodeShark> are you sure you're running as the correct user?
 768 2013-02-24 09:46:03 <CodeShark> either you don't have the config file in the right place or you're not running as the correct user
 769 2013-02-24 09:46:10 <Luke-Jr> justarandomguy: also http://www.howtogeek.com/howto/windows-vista/copy-to-the-clipboard-from-the-windows-command-prompt/
 770 2013-02-24 09:46:36 coblee_ has joined
 771 2013-02-24 09:46:39 <CodeShark> or also possibly there's an error in the file
 772 2013-02-24 09:46:45 <justarandomguy> pretty sure
 773 2013-02-24 09:47:04 idstam has quit ()
 774 2013-02-24 09:47:05 <Luke-Jr> justarandomguy: then ignore the config file and just do: bitcoind -rpcpassword=whatever
 775 2013-02-24 09:47:06 <CodeShark> make sure all comment lines have # as the first character or are blank
 776 2013-02-24 09:47:17 <CodeShark> or do what Luke-Jr says
 777 2013-02-24 09:48:09 <CodeShark> before even trying to connect to bitcoind via JSON-RPC, make sure you can access it via command line
 778 2013-02-24 09:48:38 <justarandomguy> thats what i was trying to do.  sec
 779 2013-02-24 09:48:57 <CodeShark> and before even trying to connect via PHP, try command line curl
 780 2013-02-24 09:48:59 <justarandomguy> its just hanging there now.   is that good or bad?
 781 2013-02-24 09:49:16 <CodeShark> hanging there now?
 782 2013-02-24 09:49:21 <justarandomguy> codeshark, do you have an example
 783 2013-02-24 09:49:28 <justarandomguy> yeah its hanging.
 784 2013-02-24 09:49:37 coblee has quit (Ping timeout: 240 seconds)
 785 2013-02-24 09:49:37 coblee_ is now known as coblee
 786 2013-02-24 09:49:44 <justarandomguy> i entered bitcoind and its just chilling
 787 2013-02-24 09:49:47 <CodeShark> check the debug.log file - see if it's writing anything to it
 788 2013-02-24 09:50:27 <CodeShark> as for examples of command line curl, there's one here: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#Command_line_.28cURL.29
 789 2013-02-24 09:50:44 <CodeShark> if that doesn't work, you won't be able to call it from PHP
 790 2013-02-24 09:50:52 <justarandomguy> yeah the debug file is being written too
 791 2013-02-24 09:50:59 <CodeShark> what's the debug file say?
 792 2013-02-24 09:51:08 <Luke-Jr> sounds normal for bitcoind on Windows
 793 2013-02-24 09:51:17 <Luke-Jr> minimize the console window and ignore it
 794 2013-02-24 09:51:38 <justarandomguy> lol
 795 2013-02-24 09:51:56 <Luke-Jr> in the future, might check out the RUN command
 796 2013-02-24 09:51:57 <justarandomguy> the log file is pretty long
 797 2013-02-24 09:51:59 <CodeShark> as long as the debug.log file is being written to and the messages appear normal, it's running correctly. in windows, daemonizing it is a little tricky
 798 2013-02-24 09:52:10 <justarandomguy> received getdata for: tx 057b6680a193a89b6342 CTxMemPool::accept() : accepted 97c1534f02 (poolsz 167) CTxMemPool::accept() : accepted fd163cadb1 (poolsz 168) received getdata for: tx 97c1534f022a9f81a540 received getdata for: tx 97c1534f022a9f81a540 received getdata for: tx fd163cadb1c01af7a4d1 CTxMemPool::accept() : accepted 0ebe113cbb (poolsz 169) CTxMemPool::accept() : accepted 318ea2a359 (poolsz 170) CTxMemPool::accep
 799 2013-02-24 09:52:17 <CodeShark> that looks totally normal
 800 2013-02-24 09:52:24 <justarandomguy> okay cool
 801 2013-02-24 09:52:27 <CodeShark> that's exactly what it should be doing
 802 2013-02-24 09:52:47 <CodeShark> so now try accessing it from a different console window
 803 2013-02-24 09:52:52 <CodeShark> bitcoind getinfo
 804 2013-02-24 09:53:47 <justarandomguy> couldnt connect to server
 805 2013-02-24 09:54:22 <CodeShark> hmmm
 806 2013-02-24 09:55:17 <Luke-Jr> good luck guys, I'm getting to bed now
 807 2013-02-24 09:55:24 <CodeShark> night, Luke-Jr
 808 2013-02-24 09:55:29 <justarandomguy> nice!
 809 2013-02-24 09:55:36 <justarandomguy> got it, thanks guys
 810 2013-02-24 09:55:48 <CodeShark> you're welcome
 811 2013-02-24 09:56:16 <justarandomguy> haha milestone accomplished for tonight.  bed time for me as well.
 812 2013-02-24 09:56:35 BTC_Bear has quit (Quit: Leaving...)
 813 2013-02-24 09:57:08 <justarandomguy> ./quit
 814 2013-02-24 09:57:15 justarandomguy has quit ()
 815 2013-02-24 10:05:22 Impaler has joined
 816 2013-02-24 10:18:02 B0g4r7 has quit (Ping timeout: 276 seconds)
 817 2013-02-24 10:22:58 B0g4r7 has joined
 818 2013-02-24 10:23:08 nus has quit (Read error: Connection reset by peer)
 819 2013-02-24 10:23:25 nus has joined
 820 2013-02-24 10:23:27 idstam has joined
 821 2013-02-24 10:24:28 Lone has quit (Ping timeout: 260 seconds)
 822 2013-02-24 10:25:04 denisx has joined
 823 2013-02-24 10:25:51 denisx has quit (Client Quit)
 824 2013-02-24 10:26:08 denisx has joined
 825 2013-02-24 10:29:02 RazielZ has joined
 826 2013-02-24 10:30:36 RazielZ has quit (Read error: Connection reset by peer)
 827 2013-02-24 10:34:00 RazielZ has joined
 828 2013-02-24 10:41:35 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
 829 2013-02-24 10:48:19 brwyatt is now known as brwyatt|Away
 830 2013-02-24 10:49:00 kirill42 has quit (Ping timeout: 245 seconds)
 831 2013-02-24 10:51:32 pecket has quit (Quit: I'm not stupid. I'm just unlucky when I think.)
 832 2013-02-24 10:53:10 copumpkin has quit (Ping timeout: 252 seconds)
 833 2013-02-24 10:53:45 copumpkin has joined
 834 2013-02-24 10:59:39 frosks has quit (Remote host closed the connection)
 835 2013-02-24 11:06:09 nouitfvf has joined
 836 2013-02-24 11:07:45 pecket has joined
 837 2013-02-24 11:39:35 JDuke128 has joined
 838 2013-02-24 12:06:44 tonikt has joined
 839 2013-02-24 12:07:06 axhlf has joined
 840 2013-02-24 12:08:15 darkskiez has quit (Ping timeout: 276 seconds)
 841 2013-02-24 12:09:17 Garr255 has joined
 842 2013-02-24 12:10:07 darkskiez has joined
 843 2013-02-24 12:17:07 <Goonie> fyi: I released Bitcoin Wallet 2.41 to Google Play. This will add about 10.000 peers requesting a bloom filter during the next days.
 844 2013-02-24 12:20:33 TradeFortress has quit (Ping timeout: 260 seconds)
 845 2013-02-24 12:23:14 denisx has quit (Quit: denisx)
 846 2013-02-24 12:46:26 <sipa> Goonie: there's no reason to just expect many filters the next few days, right?
 847 2013-02-24 12:46:37 <sipa> oh you mean, being added over the next days, but remain afterwards
 848 2013-02-24 12:47:47 fishfish has joined
 849 2013-02-24 12:53:15 Hashdog has joined
 850 2013-02-24 12:55:29 LainZ has joined
 851 2013-02-24 13:01:57 CaptainBlaze has joined
 852 2013-02-24 13:12:10 Impaler has quit (Remote host closed the connection)
 853 2013-02-24 13:12:15 <jouke> Goonie: thanks, just updated it and it does update a little quicker indeed :)
 854 2013-02-24 13:16:33 meLon has quit (Ping timeout: 264 seconds)
 855 2013-02-24 13:16:50 meLon has joined
 856 2013-02-24 13:21:14 fishfish has quit (Quit: Leaving...)
 857 2013-02-24 13:29:18 rbecker is now known as RBecker
 858 2013-02-24 13:35:42 <ainfo> where can i find a guide targeted at programmers/tech people like "idiot's guide to getting started with bitcoind: how to create an account, how to create a wallet, and how to receive and make transactions"?
 859 2013-02-24 13:35:51 <ainfo> (preferably with the json api all of it)
 860 2013-02-24 13:37:40 J6So4W7Yb has quit ()
 861 2013-02-24 13:39:12 okok__ has joined
 862 2013-02-24 13:39:20 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
 863 2013-02-24 13:39:21 okok_ has joined
 864 2013-02-24 13:39:30 okok__ has quit (Client Quit)
 865 2013-02-24 13:41:44 TD has joined
 866 2013-02-24 13:47:23 grau has quit (Remote host closed the connection)
 867 2013-02-24 13:48:57 <jaakkos> could mention here https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29 that the default username is empty
 868 2013-02-24 13:50:21 <sipa> Goonie: my android wallet just synced more than a day over edge (2G network), while i was checking the market whether i already had the latest version :p
 869 2013-02-24 13:50:31 <TD> good day
 870 2013-02-24 13:51:02 <TD> sipa: it synced over edge before or after the upgrade?
 871 2013-02-24 13:51:09 <sipa> after
 872 2013-02-24 13:51:20 <sipa> it autoupgraded, apparently
 873 2013-02-24 13:52:23 CodeShark has quit (Remote host closed the connection)
 874 2013-02-24 13:53:16 grau has joined
 875 2013-02-24 13:53:40 <TD> sipa: i hope it was able to find a 0.8 node then, to conserve your bandwidth
 876 2013-02-24 13:54:09 <sipa> TD: i have it connect to my VPS
 877 2013-02-24 13:54:18 <TD> cool
 878 2013-02-24 13:54:40 <sipa> i got an answer from adam langley, btw, regarding bip32
 879 2013-02-24 13:55:05 <sipa> i'll add you when i reply
 880 2013-02-24 13:55:11 <TD> thanks
 881 2013-02-24 13:55:28 <MC1984> what exactly does replaying the blockchain mean
 882 2013-02-24 13:55:42 <MC1984> and why did it take so long, with the bloom fliter stuff
 883 2013-02-24 13:56:26 <sipa> MC1984: it's an SPV node, so it downloads the blockchain but doesn't store it
 884 2013-02-24 13:56:33 HM has joined
 885 2013-02-24 13:56:39 <sipa> and bloom filtering only works if both client and server support it
 886 2013-02-24 13:56:54 <MC1984> i thought only block headers
 887 2013-02-24 13:57:13 <MC1984> and it was a 0.8 node in bold which means im downloading from it right
 888 2013-02-24 13:57:24 <sipa> it downloads headers for the part of history before the wallet existed
 889 2013-02-24 13:57:36 <sipa> but afterwards it either needs full blocks or filtered blocks
 890 2013-02-24 14:00:14 <MC1984> oh
 891 2013-02-24 14:00:31 <sipa> it only stores headers, though
 892 2013-02-24 14:00:57 <MC1984> seemed to take a while
 893 2013-02-24 14:01:02 <TD> MC1984: it should be a lot faster at that and fixing it is next on my todo list
 894 2013-02-24 14:01:11 <TD> basically it uses disk writes very inefficiently
 895 2013-02-24 14:01:29 <TD> one write per header! urgh. disk writes on tablets/phones are very slow relative to decent laptops
 896 2013-02-24 14:01:44 <TD> also, we're going to start only syncing headers from the most recent checkpoint
 897 2013-02-24 14:01:46 <MC1984> okie dokie
 898 2013-02-24 14:01:50 <TD> instead of always syncing back to the genesis block
 899 2013-02-24 14:02:11 <MC1984> aw we need less checkpoints not more!
 900 2013-02-24 14:02:14 <TD> the bloom filtering stuff makes things a lot faster when you're caught up to the head of the chain because you don't have to download full blocks anymore. but when you're just churning through years of headers, it doesn't make any difference
 901 2013-02-24 14:03:21 <sipa> what if your wallet was created before that checkpoint?
 902 2013-02-24 14:04:30 <TD> there are a series of checkpoints
 903 2013-02-24 14:04:45 <TD> it finds the one closest to the birthday of your wallet
 904 2013-02-24 14:04:45 <sipa> ok, so you use the latest one before the wallet creation
 905 2013-02-24 14:04:47 <TD> yeah
 906 2013-02-24 14:05:19 <TD> MC1984: well you don't have to use them, of course, but i think most people will want the app to be ready to go ~immediately on first run
 907 2013-02-24 14:05:38 <MC1984> is the new checkpoint sheme more for speed or security?
 908 2013-02-24 14:05:39 <TD> and we're still not there yet. getting closer all the time, bloom filtering was a big step forwards
 909 2013-02-24 14:05:43 <TD> speed
 910 2013-02-24 14:05:51 <TD> it is security-neutral. you already trust the software developers
 911 2013-02-24 14:06:11 <MC1984> i suppose
 912 2013-02-24 14:06:34 <MC1984> SPV is shaping up great though
 913 2013-02-24 14:06:48 <MC1984> next step put it in QT lol
 914 2013-02-24 14:07:09 <TD> heh
 915 2013-02-24 14:07:12 * TD is too tired to do that
 916 2013-02-24 14:07:17 <TD> it was hard enough the first time.
 917 2013-02-24 14:07:41 <MC1984> all in good time
 918 2013-02-24 14:07:54 <sipa> first step: headers-first sync
 919 2013-02-24 14:11:02 <TD> i think it's an interesting question/issue to resolve, whether Bitcoin-Qt (aka Core or whatever) should focus more on backbone type features like double spend alerts, or end-user facing features
 920 2013-02-24 14:11:19 <TD> trying to be all things to all people might not be the way to go, given limited manpower
 921 2013-02-24 14:11:38 <MC1984> need more men then
 922 2013-02-24 14:11:43 <MC1984> or women
 923 2013-02-24 14:11:45 <MC1984> whatevr
 924 2013-02-24 14:12:39 <MC1984> id like to see it continue as a complete reference client for the time being though
 925 2013-02-24 14:14:39 <HM> I think the UI should utilise the RPC interface
 926 2013-02-24 14:14:45 <HM> and be separate entirely
 927 2013-02-24 14:15:14 starsoccer has quit (Ping timeout: 264 seconds)
 928 2013-02-24 14:15:19 <MC1984> maybe
 929 2013-02-24 14:15:23 <HM> but sometimes such things are tiresome and just a distraction
 930 2013-02-24 14:15:35 <MC1984> as long as thats still completely transparent to joe internet user
 931 2013-02-24 14:16:25 reizuki__ has quit (Quit: Konversation terminated!)
 932 2013-02-24 14:16:34 starsoccer has joined
 933 2013-02-24 14:16:36 <TD> how about, fixing the RPC interface so you can actually get callbacks when money is received
 934 2013-02-24 14:16:47 <TD> as far as i know, that still isn't possible. but you need it for any website that accepts coins
 935 2013-02-24 14:17:11 <TD> that seems like a bigger need than faster initial sync
 936 2013-02-24 14:17:14 <HM> I dunno, you can take layering to extremes. it's always a trade off
 937 2013-02-24 14:17:19 <sipa> TD: -walletnotify was just merged
 938 2013-02-24 14:17:27 <TD> oh, cool
 939 2013-02-24 14:17:32 <TD> how does it work? i didn't see that pullreq
 940 2013-02-24 14:18:12 <TD> oh wow
 941 2013-02-24 14:18:15 <sipa> you can specify a script that gets executed the first time a tx enters the mempool, or the blockchain
 942 2013-02-24 14:18:15 <TD> gavin went on a merge rampage
 943 2013-02-24 14:18:34 <TD> sipa: what about other events like being double spent away?
 944 2013-02-24 14:18:59 <sipa> it's too minimal for that
 945 2013-02-24 14:19:35 <sipa> something like being able to install an RPC callback when a coin exceeds a number of confirmations would also be nice
 946 2013-02-24 14:19:42 <TD> hmm
 947 2013-02-24 14:19:47 <TD> maybe it's not
 948 2013-02-24 14:19:51 <TD> the script runs whenever the tx "changes"
 949 2013-02-24 14:20:01 <TD> i wonder what the definition of a change is here
 950 2013-02-24 14:20:14 <sipa> it changes when it's first seen, or when its merkle path is updated
 951 2013-02-24 14:20:21 <sipa> the latter happens when it's seen in a block
 952 2013-02-24 14:21:06 <sipa> i dislike the overhead a separate script execution per tx may cause
 953 2013-02-24 14:22:06 <HM> command as in, system() call if i'm viewing the code correctly.
 954 2013-02-24 14:22:30 <sipa> yes
 955 2013-02-24 14:23:18 <sipa> i think we could almost release the current git head as-is as 0.8.1 (after some rcs)
 956 2013-02-24 14:24:17 <HM> hmm
 957 2013-02-24 14:24:50 <TD> hmm, yeah.
 958 2013-02-24 14:25:02 * TD prefers the bitcoinj approach with callbacks for when tx confidence changes :)
 959 2013-02-24 14:25:03 JDuke128 has joined
 960 2013-02-24 14:25:31 <HM> so is walletnotify just a command line argument, not an rpc?
 961 2013-02-24 14:25:47 <sipa> TD: that's doable in an API, much less so in a binary
 962 2013-02-24 14:26:22 <sipa> though i agree, and ideally the wallet module entirely was available as a library that can connect to a minimalistic node
 963 2013-02-24 14:26:25 <TD> yeah
 964 2013-02-24 14:26:47 <TD> sipa: well, these days you can just connect an spv wallet to your node and get the same thing
 965 2013-02-24 14:28:07 <sipa> TD: that's basically what i'd like to see: Bitcoin-Qt becoming a separate process with its own SPV block header, and a bitcoind server to process the chain (which can run in the background, system-wide, or be spawned automatically by the GUI if nedded)
 966 2013-02-24 14:28:38 <TD> sure. so, hmm, maybe we can do that by welding together MultiBit and bitcoind :)
 967 2013-02-24 14:29:06 MobGod has quit (Ping timeout: 245 seconds)
 968 2013-02-24 14:29:26 <sipa> actually, it would be bitcoinblockd or so, and then either bitcoinwalletd or bitcoinqt
 969 2013-02-24 14:29:37 <sipa> with bitcoinwalletd the RPC server
 970 2013-02-24 14:30:53 <grau> sipa: remembers me of bitsofproof a lot :)
 971 2013-02-24 14:31:17 <sipa> grau: sure, you got a lot of things right from the start
 972 2013-02-24 14:31:23 <sipa> a luxury we don't have :)
 973 2013-02-24 14:31:30 <grau> not complaining
 974 2013-02-24 14:32:29 <grau> or telling its unique idea, but  those who start a bitcoin project (using it for something real) might be attracted exactly for this luxury
 975 2013-02-24 14:32:52 <sipa> sure
 976 2013-02-24 14:51:39 monkeynipples has joined
 977 2013-02-24 14:57:43 monkeynipple_ has joined
 978 2013-02-24 14:58:40 monkeynipples has quit (Ping timeout: 255 seconds)
 979 2013-02-24 15:10:50 <Goonie> sipa: Sorry, I was out for lunch. I meant that during the next several days, there will be a lot of clients starting to send the filterload command (also to pre-0.8.0 peers).
 980 2013-02-24 15:14:29 <Goonie> MC1984: the "replay" message is displayed if the blockchain is downloaded again due to either user request, key import or some serious error. In this state, spending coins will be disabled (not implemented yet), because that will most likely create a double spend.
 981 2013-02-24 15:15:36 <Goonie> Also, you don't get any Android notifications about received payments, because actually its an old payment because of the replay (already implemented).
 982 2013-02-24 15:16:38 tonikt has quit (Read error: Connection reset by peer)
 983 2013-02-24 15:19:04 <MC1984> cool
 984 2013-02-24 15:21:10 <sipa> Goonie: anyway, i'm very glad bloom filtering works so well :)
 985 2013-02-24 15:21:19 <Goonie> me too
 986 2013-02-24 15:22:04 <sipa> does it use compressed pubkeys now too?
 987 2013-02-24 15:22:14 <sipa> (for new addresses only, obviously)
 988 2013-02-24 15:22:19 <Goonie> yes
 989 2013-02-24 15:22:23 <sipa> good!
 990 2013-02-24 15:24:19 <ainfo> td: how mature is bitcoinj for taking care of real bitcoinw ork and all the blockchain? fiort he altter it wsays "experimental" on their page
 991 2013-02-24 15:25:37 MobiusL has quit (Remote host closed the connection)
 992 2013-02-24 15:25:37 sacredchao has quit (Write error: Connection reset by peer)
 993 2013-02-24 15:26:34 <ainfo> sipa: where can i read about walletnotify?
 994 2013-02-24 15:26:50 <sipa> ainfo: only source code, at this point
 995 2013-02-24 15:29:41 daybyter has joined
 996 2013-02-24 15:29:51 <ainfo> sipa: aha. ah i see th commit there, https://github.com/bitcoin/bitcoin/pull/1974 , it launches a separate OS process. aha.
 997 2013-02-24 15:31:23 <TD> ainfo: well the full verify code is new
 998 2013-02-24 15:31:38 <TD> i would say all fully verifying codebases are experimental
 999 2013-02-24 15:32:19 <TD> ainfo: for running wallets it's ok. not perfect but what software is?
1000 2013-02-24 15:32:45 monkeynipple_ has quit (Ping timeout: 264 seconds)
1001 2013-02-24 15:33:11 sacredchao has joined
1002 2013-02-24 15:33:12 <grau> td: until majority of nodes is Satoshi, is it really a danger to the network (other than the own wallet) to use an other codebase?
1003 2013-02-24 15:33:23 <MC1984> is there any sort of shopping cart/checkout thing that people can plug into their merchant sites
1004 2013-02-24 15:33:38 <MC1984> but where they run bitcoin an receive coins themselves
1005 2013-02-24 15:33:44 <MC1984> no middle man?
1006 2013-02-24 15:34:19 <TD> grau: if you aren't mining with it, then no danger to the network. just to people who are using it
1007 2013-02-24 15:34:36 <TD> MC1984: there are a bunch of plugins for common cart software yes
1008 2013-02-24 15:34:53 MobPhone has joined
1009 2013-02-24 15:35:01 <grau> td: might be even true for the miner. He risks losing money if mining an invalid block.
1010 2013-02-24 15:35:12 <MC1984> what are the good ones?
1011 2013-02-24 15:35:26 sacredchao has quit (Remote host closed the connection)
1012 2013-02-24 15:35:26 <sipa> grau: sure, running buggy software is always a risk to the one running it
1013 2013-02-24 15:35:34 <TD> well, if people mine on alt implementations then a chain-splitting bug can reduce the overall network hash rate very suddenly, which reduces the cost of a double spend attack
1014 2013-02-24 15:35:41 <sipa> but i see no real dangers for others, unless you are mining with it
1015 2013-02-24 15:35:44 <TD> MC1984: not sure sorry. i never set one up.
1016 2013-02-24 15:35:52 <MC1984> ok
1017 2013-02-24 15:36:05 <grau> sipa: Exactly, If you do business with a software you risk your money with it. Bitcoin implementations are no exception
1018 2013-02-24 15:37:32 <grau> I understand that mining is somewhat special, but still even a mined invalid block is just the problem of the miner until the majority rejects it since using an other implementation
1019 2013-02-24 15:38:49 <sipa> not really
1020 2013-02-24 15:38:57 <grau> what am I missing?
1021 2013-02-24 15:39:09 <sipa> but it does requires at least some other users and miners to be using the same implementation
1022 2013-02-24 15:39:09 <HM> if one implementation has a bug and the userbase is 50/50, you still lose half the network
1023 2013-02-24 15:39:47 <sipa> it's not really necessary for having a majority of deployment before a bug in the consistency rules can be threatening
1024 2013-02-24 15:39:51 <grau> I guess miner seek to achive highest compliance, so their blocks are accepted by the majority
1025 2013-02-24 15:40:16 okok_ has quit (Ping timeout: 245 seconds)
1026 2013-02-24 15:41:50 <TD> obviously
1027 2013-02-24 15:41:54 <TD> but achieving that is something else
1028 2013-02-24 15:43:18 <grau> Simplest to acheive if there is no choice. This is however less and less the case. Do we know how miner will upgrade to 0.8 e.g.
1029 2013-02-24 15:43:56 <sipa> i believe some pools have already switched to 0.8 code
1030 2013-02-24 15:43:58 <ainfo> td: fully verifying as in what bitcoind does by default?
1031 2013-02-24 15:44:18 <sipa> ainfo: yes
1032 2013-02-24 15:44:33 <ainfo> ainfo: i'm trying to figure out how to make a programmed/programmable multi-wallet bitcoin setup
1033 2013-02-24 15:45:01 <TD> grau: cool you fixed the bug i mentioned on your thread
1034 2013-02-24 15:45:09 <grau> thanks!
1035 2013-02-24 15:45:10 <sipa> ainfo: there is a pull request by CodeShark to add native multiwallet support to bitcoind/bitcoin-Qt
1036 2013-02-24 15:45:38 <grau> I am nearly done with the blocktester of bitconj - I mean bitsofproof complies it
1037 2013-02-24 15:45:43 <TD> grau: the bug i had in mind, was that in CachedBlockStore.validateTransaction tcontext.nsigs was being incremented without any locking, so your old code would sometimes undercount the number of sigops in a block
1038 2013-02-24 15:45:53 <TD> grau: meaning that you'd accept some blocks that violated the rules
1039 2013-02-24 15:46:05 <TD> grau: but i see now that all accesses to tcontext are now synchronized. so the bug seems fixed.
1040 2013-02-24 15:46:19 <grau> Yes, I think I fixed that longer ago.
1041 2013-02-24 15:46:20 <ainfo> please have a bit of tolerance with some extremely basic questions i may ask around now =)
1042 2013-02-24 15:46:26 <TD> probably. i didn't look for a while.
1043 2013-02-24 15:46:27 <grau> Currently struggling with blocksize
1044 2013-02-24 15:46:56 <TD> ainfo: with bitcoinj you can have multiple wallets, but you can't detach them once created, so it's not quite as useful as it could be. and it's not that well tested.
1045 2013-02-24 15:46:57 <grau> The bitcoinj test b64 generates a block that is raw size 1000008
1046 2013-02-24 15:47:07 <ainfo> sipa: so it's not in there yet? in what sense could you say that the mutliwallet support in bitcoind now is not native?
1047 2013-02-24 15:47:22 <sipa> ainfo: in the sense that it only manages a single wallet
1048 2013-02-24 15:48:31 <ainfo> sipa,td: in what sense could a fully verifying codebase be said to experimental now? i mean, they've been used for more than two years now without one transaction error, and the 51% problem and alike is inherent to the algorith, so, how could they be experimental?
1049 2013-02-24 15:48:43 <ainfo> td: what about in bitcoind ?
1050 2013-02-24 15:49:16 <TD> ainfo: the "experimental" tag only applies to bitcoinj in fully verifying mode. bitcoind is i think a bit beyond an experiment now
1051 2013-02-24 15:49:26 <TD> at least only to the extent that all of bitcoin is one huge experiment
1052 2013-02-24 15:49:50 <ainfo> td: aha right. so you mean that the fully verifying mechanism is to be considered solid - yes this makes good sense.
1053 2013-02-24 15:49:56 <grau> sipa, TD: what is the blocksize limit really applied to. The message size, the block size or below. I see that bitcoinj blocktester case b64 creates a block with bloc.unsafeBitcoinSerialize ().size () = 1000008 and it is accepted by bitcoind/j, why ?
1054 2013-02-24 15:50:14 <ainfo> now, what is the anatomy of a bitcoin client setup (bitcoind i'm thinking of primarily, bitcoinj very secondarily);
1055 2013-02-24 15:50:24 <ainfo> you set up "accounts" and each account contains a set of "wallets"?
1056 2013-02-24 15:50:30 <ainfo> is that the structure?
1057 2013-02-24 15:50:45 <TD> no
1058 2013-02-24 15:50:47 <TD> you have one wallet
1059 2013-02-24 15:50:49 ralphtheninja has joined
1060 2013-02-24 15:50:58 <TD> each wallet may contain multiple accounts. but, an account is a somewhat weak abstraction.
1061 2013-02-24 15:51:03 <TD> it doesn't control which coins are spent
1062 2013-02-24 15:51:06 <TD> it's just an accounting feature
1063 2013-02-24 15:51:24 <sipa> grau: it should apply to the full serialied blocks, i.e. 80-byte block header + tx count + transactions
1064 2013-02-24 15:51:57 <grau> ainfo: If you need multiple wallets and willing to try new you need an implementation that separates that concern clearly. look at bitsofproof.
1065 2013-02-24 15:52:41 <ainfo> grau: em - so all the mutliple-wallets services like mtgox, flexcoin etc. do *not* use nor bitcoind nor bitcoinj???
1066 2013-02-24 15:52:46 <grau> sipa: That is what I thought. but that seem to be 8 bytes longer on the test case
1067 2013-02-24 15:52:57 monkeynipples has joined
1068 2013-02-24 15:53:10 <grau> ainfo: not out of the box
1069 2013-02-24 15:53:18 <sipa> ainfo: they implement the wallets in an accounting layer on top
1070 2013-02-24 15:53:56 <sipa> in particular for mtgox, they technically have just one wallet, as coins are not kept separately for each customer
1071 2013-02-24 15:54:02 <ainfo> aha interesting, so by default both bitcoind and bitcoinj support *one* bitcoin address olnoy - ok
1072 2013-02-24 15:54:03 <sipa> so they have one wallet + a balance per customer
1073 2013-02-24 15:54:20 <sipa> ainfo: no a wallet certainly consists of many (possible very many) addresses
1074 2013-02-24 15:54:22 <ainfo> by wallet, we mean one bitcoina ddress (i.e. pubkey+privkey pair), no?
1075 2013-02-24 15:54:22 sacredchao has joined
1076 2013-02-24 15:54:30 <ainfo> aha! ah i got it
1077 2013-02-24 15:54:45 <sipa> no, a wallet is a collection of unspent transaction outputs belonging to certain addresses, and they private keys to those addresses
1078 2013-02-24 15:54:49 <ainfo> is the wallet definition part of the Bitcoin specification in any way, i mean, the bitcoin protocol is only about transactions right?
1079 2013-02-24 15:55:01 <sipa> wallet/accounts are purely client side
1080 2013-02-24 15:55:06 <sipa> they don't exist at the protocol level
1081 2013-02-24 15:55:20 <sipa> addresses actually don't exist either at the protocol level - only output scripts
1082 2013-02-24 15:55:30 <ainfo> aha, so a wallet is a set of bitcoin addresses and thus by implication their balances
1083 2013-02-24 15:55:33 <ainfo> ok
1084 2013-02-24 15:56:07 <sipa> grau: very strange
1085 2013-02-24 15:56:13 <ainfo> sipa: addresses don't exist at the protocol level - oh my =)    wcan you clarify this?  i find it interesting considering that what you see from the "outside" is that bitcoin is a system of making transactions between bitcoin addresses.
1086 2013-02-24 15:56:51 MobGod has joined
1087 2013-02-24 15:57:01 <TD> ainfo: yeah kind of. i don't know what mtgox uses, a custom implementation i think.
1088 2013-02-24 15:57:02 <sipa> ainfo: a transaction is not between addresses
1089 2013-02-24 15:57:35 <sipa> ainfo: a transaction consumes _specific_ outputs of previous transaction(s), and assigns them to a pubkeyScript
1090 2013-02-24 15:57:42 <TD> ainfo: you can read the white paper written by satoshi to understand more: http://bitcoin.org/bitcoin.pdf
1091 2013-02-24 15:57:51 <sipa> eh, and splits the amount into new outputs, which are assigned to pubkeyScripts
1092 2013-02-24 15:57:57 <ainfo> td: yeah, ki'm on page 2 there now
1093 2013-02-24 15:58:00 <ainfo> 3
1094 2013-02-24 15:58:04 <sipa> an address is technically a template for a specific script
1095 2013-02-24 15:58:28 <sipa> but scripts - which exists at the protocol level - are much more flexible
1096 2013-02-24 15:58:37 <ainfo> wow. i'm very glad that you clarify that the elements of bitcoin are not at all what i would have guessed. =)
1097 2013-02-24 15:59:38 <sipa> but the inputs to transactions are _not_ addresses (or scripts), they refer to previous transactions
1098 2013-02-24 15:59:55 <sipa> (and supply a signature to prove ownership of that previous output being consumed)
1099 2013-02-24 16:00:04 <ainfo> now, just so i kind of get this: i wish to understand how i can create a Bunch of bitcoin addresses (i.e. pubkey+privkey pairs) - both how the generation is done and how i make my bitcoind work with them -  and then i want to be able to register incoming transactions to them, and, make outgoing transactions to bitcoin addresses.   all bitcoind interaction made via the rpc api preferably.  how is this done, approx approx?
1100 2013-02-24 16:00:17 <ainfo> what terms or functionality will i use, and approx what api calls?
1101 2013-02-24 16:00:59 <ainfo> sipa: does this mean that the blockchain needs Alot of data processing as to calculate the balance of each bitcoin address?  or is bitcoind containing an index of all bitcoina ddresses with current balance?
1102 2013-02-24 16:01:10 <jouke> Why do you want to create those adresses yourself and not let bitcoind do that?
1103 2013-02-24 16:01:31 <sipa> blockchain maintains an index to find all transactions affecting a specific address quickly
1104 2013-02-24 16:01:32 <ainfo> jouke: i'm completely ok that bitcoind creates the addresses. i just want to be able to create them on demand.
1105 2013-02-24 16:01:38 <sipa> bitcoind doesn't have that, and doesn't need that
1106 2013-02-24 16:01:46 <sipa> it looks things up by txid, not by address
1107 2013-02-24 16:02:06 <sipa> s/blockchain/blockchain.info/
1108 2013-02-24 16:02:13 <ainfo> sipa: blockchain as the web site blockchain.info, or you mean bitcoin's blockchain - that by just .. right
1109 2013-02-24 16:02:44 <ainfo> so i could easily make a piece of software to calcualte the current balance of a bunch of bitcoin addresses, and all there is to it are optimization problems i guess
1110 2013-02-24 16:03:01 <sipa> if that program just rescans the entire blockchain, sure
1111 2013-02-24 16:03:07 <sipa> but you certainly don't want that
1112 2013-02-24 16:03:35 <sipa> since 0.8, bitcoin maintains a database with an explicit representation of all unspent transaction outputs
1113 2013-02-24 16:03:39 <ainfo> sipa: would you say that bitcoin address is an elemental part of the bitconi spec? or they're just an arbitrary construction atop it?
1114 2013-02-24 16:03:56 <ainfo> bitcoind. aha.
1115 2013-02-24 16:04:14 <sipa> it's a construction on top, but it's such a pervasive one, that's easy to miss that it exists at all
1116 2013-02-24 16:04:16 <ainfo> sipa: by address, right? i.e. ean index of unspent transaction outputs per bitcoin address?
1117 2013-02-24 16:04:24 <sipa> no, by txid
1118 2013-02-24 16:04:28 <jouke> ainfo: you can easily create address on demand with bitcoind and let the bitcoind wallet keep track of all the relevant transactions.
1119 2013-02-24 16:04:33 <sipa> addresses _do not_ exist at the protocol level :)
1120 2013-02-24 16:05:11 <ainfo> sipa: so essentially at the protocol level, what exist is like "hey, i wish to use these unspent transaction outputs A B C D E and make a new transaction F out of it with these params G H?" ?
1121 2013-02-24 16:05:31 <sipa> bitcoin's block chain validation code doesn't use addresses anyway, they are a user-interface thing
1122 2013-02-24 16:05:46 <sipa> ainfo: basically, yes
1123 2013-02-24 16:06:17 <sipa> it combines previous unspent outputs, and creates new unspent outputs (whose sum in value doesn't exceed that of the consumed ones)
1124 2013-02-24 16:06:52 <grau> sipa: CBlock::CheckBlock seem to apply MAX_BLOCK_SIZE to transaction vector size ?
1125 2013-02-24 16:07:02 <ainfo> jouke: which bitcoind API call is used to generate a new bitcoin address?
1126 2013-02-24 16:07:23 ralphtheninja has quit (Quit: leaving)
1127 2013-02-24 16:07:23 <sipa> grau: i guess it does that as an optimization, checking the vector size before checking the actual serialized size
1128 2013-02-24 16:07:32 <ainfo> sipa: does this mean that theoretically the address definition could be changed to fit more than 2^160 addresses?
1129 2013-02-24 16:07:36 <sipa> ainfo: sure
1130 2013-02-24 16:07:42 <ainfo> cool!
1131 2013-02-24 16:07:47 <ainfo> is there an upper limit of transactions
1132 2013-02-24 16:07:54 <jouke> ainfo: getnewaddress
1133 2013-02-24 16:07:57 <ainfo> ? (btc transactions in total)
1134 2013-02-24 16:07:57 <jouke> https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
1135 2013-02-24 16:07:58 <sipa> 2^256, i'd say
1136 2013-02-24 16:08:13 <sipa> since transactions are identified using their 256-bit hash
1137 2013-02-24 16:08:55 <sipa> grau: that could easily be changed to (MAX_BLOCK_SIZE-BLOCK_HEADER_SIZE)/MIN_TX_SIZE, I guess
1138 2013-02-24 16:09:14 <ainfo> sipa: aha. so if this is reached (2^256), then the bitcoin community would get into some kind of extension or redefinition work and it'd be solved thast way?
1139 2013-02-24 16:09:28 <ainfo> like, people download an upgratde that extends the db to 2^4096 or sth
1140 2013-02-24 16:09:38 <sipa> ainfo: if you say "2^256" and "reach" in the same sense, you need to understand powers of two better
1141 2013-02-24 16:10:01 <ainfo> sipa: yeah, 2^256 is an incredible amount indeed.  hmm
1142 2013-02-24 16:10:03 <HM> addresses all start with 1, so adding a new format is fairly straightforward
1143 2013-02-24 16:10:12 <TD> hmm, btcguild is at 25% of mining capacity
1144 2013-02-24 16:10:25 <sipa> 2^256 = 115792089237316195423570985008687907853269984665640564039457584007913129639936
1145 2013-02-24 16:10:37 <HM> hey, that's the combination on my luggage
1146 2013-02-24 16:10:47 monkeynipples has quit (Read error: Connection reset by peer)
1147 2013-02-24 16:10:54 <sipa> TD: many asics there?
1148 2013-02-24 16:11:09 <ainfo> that'sw a lot indeed. it's like 10000000000000000 transactions each for 1000000000000000 people for 10000000000000000 generations. yeah it should not be an issue. :)
1149 2013-02-24 16:11:23 <ainfo> cool.
1150 2013-02-24 16:12:07 MobiusL has joined
1151 2013-02-24 16:12:11 monkeynipples has joined
1152 2013-02-24 16:12:17 <ainfo> question: how hardwired is a bitcoin address to aparticular bitcoind installation?
1153 2013-02-24 16:12:18 <sipa> ainfo: just _counting_ to 2^256 requires more energy than boiling the coans
1154 2013-02-24 16:12:25 <sipa> *oceans
1155 2013-02-24 16:12:31 <ainfo>  :)
1156 2013-02-24 16:12:54 <HM> that's a lot of fish soup
1157 2013-02-24 16:12:56 <sipa> ainfo: a wallet knows its keys, and is the authority that creates addresses
1158 2013-02-24 16:12:58 <TD> sipa: friedcat is up to 4.3Thash/sec on btcguild
1159 2013-02-24 16:13:36 <ainfo> so i understand that it may be a quite huge computational effort to determine the balance of a particular bitcoin address if you're not on a machine that tracked it ind etail since the inception of that bitcoin address.
1160 2013-02-24 16:13:37 <sipa> ... that's almost worrying
1161 2013-02-24 16:13:46 <ainfo> sipa: aren't the addresses compkletely arbitrary, like, a random value only?
1162 2013-02-24 16:14:17 <ainfo> td,sipa: mm, more asics need to come out soon.
1163 2013-02-24 16:14:32 <sipa> ainfo: one example is that EC secp256k1 public keys can be encoded in two ways (a short 33-byte one, and a longer 65-byte one which is the default)
1164 2013-02-24 16:14:43 <ainfo> td: that means they mine bitcoins at a quite high rate right now, doesn't it
1165 2013-02-24 16:15:08 <sipa> ainfo: as addresses are defined as base58(0 + hash160(pubkey)), it depends on how the pubkey is serialized
1166 2013-02-24 16:15:41 <sipa> ainfo: if you give me an address, and someone pays to that address, and you spend it, the transaction spending it will reveal the full public key that was used to create the address
1167 2013-02-24 16:15:44 <ainfo> aha, so the bitcoin address *is* not the pubkey but it's the *hash* of the pubkey - noted.
1168 2013-02-24 16:16:11 MobiusL has quit (Remote host closed the connection)
1169 2013-02-24 16:16:13 <sipa> ainfo: at that point, i could argue "i know X owns pubkey Y, let me use the other serialization of that pubkey, hash it, and pay to the address derived from that"
1170 2013-02-24 16:16:34 <sipa> ainfo: it should be clear that i cannot expect you to be able to spend that (your wallet software may not understand that other pubkey serialization)
1171 2013-02-24 16:16:50 <sipa> even though i theoretically know you can
1172 2013-02-24 16:17:01 <TD> ainfo: well, Avalon is shipping, apparently, albiet kinda slowly
1173 2013-02-24 16:17:07 <TD> so i'm sure this is only a temporary situation
1174 2013-02-24 16:18:26 <ainfo> sipa: i did not understand what point you intended to make with the last three lines you wroet; is your point that by disclosing the pubkey, others *cannot* make transactions from your accounts (ie.. steal your btc:s)
1175 2013-02-24 16:18:55 <sipa> ainfo: address could well have been full pubkeys, there is no danger in that
1176 2013-02-24 16:19:09 <ainfo> td: mm. it's something like 2-10% of the total hash rate of the btc world currently, isn't it?
1177 2013-02-24 16:19:12 <sipa> the fact that they are hashes of it, is not a security feature, it just makes them a bit shorter
1178 2013-02-24 16:19:19 <TD> yeah
1179 2013-02-24 16:19:22 <ainfo> aha
1180 2013-02-24 16:19:30 <TD> well what matters really is the pool, as that's what decides what mining is done
1181 2013-02-24 16:19:35 <TD> so they're 1/4 of total hash power
1182 2013-02-24 16:20:23 <sipa> afk
1183 2013-02-24 16:20:39 <ainfo> now i'd wish to get clear about thef ollowing: so, a bitcoin address is essentially a pubkey+privkey pair. does not this mean that essentially i could just use *any* bitcoin client and just make a single request akin to "hey here's my pubkey and privkey, now please move X BTC to the address Y"?
1184 2013-02-24 16:20:56 <sipa> ainfo: an address is just a public key - _certainly_ not a private key
1185 2013-02-24 16:21:06 <sipa> a private key is never revealed
1186 2013-02-24 16:21:15 <sipa> it's the way you proof ownership of coins
1187 2013-02-24 16:21:21 <sipa> with the private key, anyone can take them
1188 2013-02-24 16:21:29 <ainfo> TD: that is a lot indeed. aha, so it's not just one unit or machine that does those terrahashes now, but many, though they happen to be in one pool?
1189 2013-02-24 16:21:43 <sipa> ainfo: probably
1190 2013-02-24 16:22:05 <ainfo> sipa: yes i know; i was just lookingf for that both pubkey and privkey are part of the bitcoin address' "deifnition" in that in order to use it fully /(both receive and sendsf rom it), you need both
1191 2013-02-24 16:22:26 <sipa> yes, to spend you need the private part
1192 2013-02-24 16:22:38 <sipa> you can ask wallet software to give you the generated private keys
1193 2013-02-24 16:22:44 <sipa> but they're typically not used or visible
1194 2013-02-24 16:22:47 <ainfo> sipa: now, so this is all the state there is to a bitcoin address? or is there more?
1195 2013-02-24 16:23:06 <ainfo> i mean, if i want to host 1000 bitcoin addresses in some kind of system i make, how hardwired to they need to be to a bitcoind installation? not a tall, or, tightly?
1196 2013-02-24 16:23:17 D34TH has joined
1197 2013-02-24 16:23:18 D34TH has quit (Changing host)
1198 2013-02-24 16:23:18 D34TH has joined
1199 2013-02-24 16:23:23 <sipa> ainfo: oh you can calculate keys offline, and then import them
1200 2013-02-24 16:23:37 <ainfo> i understand bitcoind has some "wallet.dat" files, of what use are they beyond just containing the pubkey and privkey? if i just have a pubkey and privkey,c an i create a wallet.dat file extremely easily?
1201 2013-02-24 16:23:39 <sipa> giving a wallet access to the balance of unspent coins sent to them
1202 2013-02-24 16:23:42 <HM> there's a 1% probability of hash collision in a 160 bit hash with just 2^77 iterations. divided over 6 billion people that's still 25 trillion wallets each
1203 2013-02-24 16:23:54 <ainfo> sipa: offline calculation works bc the probability of hitting one used elsewhere is so low right?
1204 2013-02-24 16:23:56 <sipa> ainfo: no, wallet.dat also contains the transactions affecting those addresses
1205 2013-02-24 16:24:02 <sipa> ainfo: yes
1206 2013-02-24 16:24:28 <ainfo> sipa: let's hypthehtise that i waste my wallet.dat file extremely frequently. is that an issue?
1207 2013-02-24 16:24:30 <sipa> ainfo: unless your RNG is broken, you won't ever have collisions on 256-bi value
1208 2013-02-24 16:24:33 <ainfo> like, after each transaction i make for instance.
1209 2013-02-24 16:24:39 <sipa> define "waste"
1210 2013-02-24 16:24:43 <ainfo> sipa: rm .
1211 2013-02-24 16:24:47 <HM> it's much more likely someone will fuck up a RNG in some widely used implementation and end up giving people identical wallets
1212 2013-02-24 16:24:48 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
1213 2013-02-24 16:24:50 <ainfo> dd if=/dev/zero of=wallet.dat count=lots
1214 2013-02-24 16:24:56 <sipa> ainfo: that'd be painful
1215 2013-02-24 16:24:58 * HM looks at debian
1216 2013-02-24 16:25:07 <ainfo> sipa: how painful?
1217 2013-02-24 16:25:12 <sipa> you'd lose access to the coins assigned to the addresses in that wallet
1218 2013-02-24 16:25:16 <ainfo> sipa: what amount of computational power would be needed to recover?
1219 2013-02-24 16:25:26 <ainfo> oh really, that painful??
1220 2013-02-24 16:25:27 <sipa> ainfo: for all practical purposes, infinity
1221 2013-02-24 16:25:30 <ainfo> so wallet. dat Must Not Be Lost?
1222 2013-02-24 16:25:34 <sipa> indeed
1223 2013-02-24 16:25:35 <ainfo> whoa
1224 2013-02-24 16:25:36 <sipa> make backups
1225 2013-02-24 16:25:49 <ainfo> wait.. can't it be recalculated from scratch, wallet.dat, as long as i have the pubkey and privkey? if not, why?
1226 2013-02-24 16:26:01 <sipa> if you have the private key, it can be recalculated, sure
1227 2013-02-24 16:26:08 <sipa> but wallet.dat is what contains the private key
1228 2013-02-24 16:26:16 Mrcheesenips has quit (Read error: Connection reset by peer)
1229 2013-02-24 16:26:18 <sipa> hence: make backups
1230 2013-02-24 16:26:20 <ainfo> right. but say i generated all of them offline and then imported them
1231 2013-02-24 16:26:26 <sipa> no problem in that case
1232 2013-02-24 16:26:31 <ainfo> and i have a backup of the offline material but just trash all myw allet.dat:s all the time
1233 2013-02-24 16:26:34 <ainfo> aha.
1234 2013-02-24 16:26:35 <sipa> it may take 10 minutes to find all transactions again
1235 2013-02-24 16:26:41 <ainfo> what kind fo computation expense is it to .. aha
1236 2013-02-24 16:26:41 Mrcheesenips has joined
1237 2013-02-24 16:26:59 <sipa> some software can do it faster if it has an index
1238 2013-02-24 16:27:08 * sipa afk
1239 2013-02-24 16:27:08 <sipa> cya
1240 2013-02-24 16:27:11 <ainfo> sipa: is that amount of time a function of the total blcoklist db size currently, or a function of the total number of transactions made with that address iin total?
1241 2013-02-24 16:27:14 <ainfo> ok
1242 2013-02-24 16:27:21 <ainfo> sipa: was great to speakw ith you :) thanks, have a great continued weekend
1243 2013-02-24 16:27:52 <ainfo> what software did sipa talka bout, that can recover the transactions from a btc address(pub+priv)?
1244 2013-02-24 16:28:05 <sipa> armory for example
1245 2013-02-24 16:28:31 <sipa> but you shouldn't rely on that
1246 2013-02-24 16:28:48 <ainfo> sipa: why?
1247 2013-02-24 16:28:51 <sipa> just don't lose your wallet.dat - rescanning the chain is an expensive operation
1248 2013-02-24 16:28:56 <ainfo> aha
1249 2013-02-24 16:29:03 <ainfo> so i should view that as a emergency-only situation
1250 2013-02-24 16:29:08 MobiusL has joined
1251 2013-02-24 16:29:09 <sipa> imho, yes
1252 2013-02-24 16:29:40 <ainfo> could anything go wrong or what?
1253 2013-02-24 16:34:50 <ainfo> whoa, i just learned quite a lot about bitcoin. :)
1254 2013-02-24 16:38:44 Guest32273 has quit (Read error: Connection reset by peer)
1255 2013-02-24 16:43:11 <ainfo> what's a sample implementation of an offline bitcoin address(pub0+priv) generator?
1256 2013-02-24 16:45:09 JDuke128 has joined
1257 2013-02-24 16:48:11 <gavinandresen> ainfo: that'd be a great question for http://bitcoin.stackexchange.com/
1258 2013-02-24 16:51:52 <sipa> gavinandresen: this looks like a problem: http://www.reddit.com/r/Bitcoin/comments/18w8hc/please_upgrade_to_bitcoin_08_and_help/c8iwjl1
1259 2013-02-24 16:53:13 robocoin has joined
1260 2013-02-24 16:53:17 <gavinandresen> yes, definitely looks like a problem. I don't know nuthin about windows network-mapped drives.
1261 2013-02-24 16:55:29 bitafterbit has joined
1262 2013-02-24 16:55:35 Guest32273 has joined
1263 2013-02-24 16:58:14 <grau> TD: I can not run the blocktester as is as it assumes that the implementation it tests processes block and ping messages sequentially while mine is multithreaded in that respect.
1264 2013-02-24 16:58:57 <ainfo> gavinandresen: you're right. though also, the questions here are logged online so they do get published
1265 2013-02-24 16:59:06 <ainfo> thoug indexing is not as good at all you're right
1266 2013-02-24 16:59:50 <grau> Therefore I serialize the blocks the testcase generates using block.unsafeBitcoinSerialize but that gives in case of b64 a block length of 1000008
1267 2013-02-24 17:00:19 <grau> Is that correct?
1268 2013-02-24 17:01:29 <grau> TD, sipa, gmaxwell: besides the exception above bitsofproof passes the bitcoij blocktester
1269 2013-02-24 17:01:54 <ainfo> what is the design of an offline wallet feature? i mean, in what way does it bring any security
1270 2013-02-24 17:02:13 copumpkin has quit (Ping timeout: 252 seconds)
1271 2013-02-24 17:02:49 copumpkin has joined
1272 2013-02-24 17:02:50 DaQatz has joined
1273 2013-02-24 17:03:03 <grau> ainfo: You store private key on a piece of paper, so it can not be stolen through network
1274 2013-02-24 17:04:04 <grau> ainfo: visit https://www.bitaddress.org for nice paper wallets
1275 2013-02-24 17:05:40 da2ce7_d has joined
1276 2013-02-24 17:05:51 <ainfo> grau: cool!
1277 2013-02-24 17:06:00 <ainfo> what is the mathematical relation between the pubkey and privkey in a bitcoina ddress?
1278 2013-02-24 17:06:24 <HM> ainfo:  point multiplication on an elliptic curve
1279 2013-02-24 17:06:34 <sipa> ainfo: they are elliptic curve scalars (private keys) and elliptic curve points (pubkeys)
1280 2013-02-24 17:06:47 <sipa> grau: nice, but that size issue is strange
1281 2013-02-24 17:07:11 <HM> ainfo: i like this video https://www.youtube.com/watch?v=XmygBPb7DPM
1282 2013-02-24 17:07:30 <gavinandresen> ainfo: http://bitcoin.stackexchange.com/questions/1389/how-are-public-private-keys-in-an-address-created
1283 2013-02-24 17:07:37 TD has quit (Ping timeout: 246 seconds)
1284 2013-02-24 17:08:08 da2ce7 has quit (Ping timeout: 260 seconds)
1285 2013-02-24 17:08:56 <gavinandresen> … some guy named Pieter gave a really good answer there....
1286 2013-02-24 17:10:16 <jaakkos> hmm. i can make bitcoind segfault when i make a lot of RPC requests...
1287 2013-02-24 17:10:34 <gavinandresen> unlocking the wallet?
1288 2013-02-24 17:10:42 <jaakkos> nope
1289 2013-02-24 17:10:49 <jaakkos> just requesting blocks and txes
1290 2013-02-24 17:10:54 <jaakkos> ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
1291 2013-02-24 17:10:54 <jaakkos> Segmentation fault
1292 2013-02-24 17:11:02 <jaakkos> method=getblock
1293 2013-02-24 17:11:08 <jaakkos> that happens randomly
1294 2013-02-24 17:11:16 <gavinandresen> file an issue at github please
1295 2013-02-24 17:13:19 TD has joined
1296 2013-02-24 17:13:19 <TD> grau: i don't think that's an unreasonable assumption. for instance bitcoinj assumes that in some cases when it's doing dependency resolution. it's sort of a hack around the minimalism of the protocol but it works
1297 2013-02-24 17:13:27 <TD> grau: you'd have to disable that. but generally, there is software that assumes ordering of message processing on a per-peer basis
1298 2013-02-24 17:13:45 <ainfo> jaakkos: run gdb on bitcoind and make it crash again!
1299 2013-02-24 17:13:46 <TD> grau: otherwise, congrats! passing matts tester is a huge step
1300 2013-02-24 17:13:53 <ainfo> in gdb, run the "bt" command, might providfe a lot of clarity
1301 2013-02-24 17:14:02 <ainfo> so just, "gdb bitcoind " and type "run"
1302 2013-02-24 17:14:36 <grau> TD: Thanks. Now I will have to add on top as I promised.
1303 2013-02-24 17:14:41 <TD> cool
1304 2013-02-24 17:14:44 <jaakkos> ainfo: yes i'm just debugging it
1305 2013-02-24 17:15:20 <grau> TD: His tester works by sending block, then ping and assuming that block is processed as pong comes. In my case this is asynchron
1306 2013-02-24 17:15:52 <grau> TD: therefore I rather dump what he sends into a file and feed that into mine. This is not a P2P test though, but deeeper.
1307 2013-02-24 17:16:06 <grau> TD: I will have to figure a P2P test without this assumption
1308 2013-02-24 17:17:39 <ainfo> so within bitcoin, a pubkey is *awlays* generatable out of the privkey because of the particular crypto mechanism used for the pub+privkey pairs?
1309 2013-02-24 17:18:07 <gmaxwell> grau: Blocktester depends on ping messages? really?  Any idea why?
1310 2013-02-24 17:18:18 <jaakkos> segfaults in libboost_thread, start_thread -> clone()...
1311 2013-02-24 17:18:42 <jaakkos> bitcoind appears to create tons of threads
1312 2013-02-24 17:19:12 <grau> gmaxwell: let me dig the code and explain
1313 2013-02-24 17:19:22 <TD> grau: you could also have a mode where you force serialization on a connection
1314 2013-02-24 17:19:42 <TD> gmaxwell: it's the only way to know when the remote nodes message loop has cleared and finished, for messages that aren't expected to generate a response otherwise
1315 2013-02-24 17:20:00 <TD> gmaxwell: bitcoinj relies on this assumption when walking pending transactions of a newly broadcast transaction (to look for nLockTimes)
1316 2013-02-24 17:20:03 <grau> I will do that probably ... Now I just got the tests work
1317 2013-02-24 17:20:15 <TD> because getdata on transactions that aren't in the mempool == silence, for old nodes (before i added the notfound message)
1318 2013-02-24 17:20:30 <TD> http://users.ece.cmu.edu/~jmmccune/papers/VaMcNePevDo2012.pdf
1319 2013-02-24 17:20:36 <TD> this is a very interesting paper
1320 2013-02-24 17:20:47 WeLoveCP has quit (Ping timeout: 255 seconds)
1321 2013-02-24 17:20:53 <jaakkos> building it with debug symbols
1322 2013-02-24 17:21:12 <sipa> grau: do you calculate the size of the sent block, or of its (re)serialization?
1323 2013-02-24 17:21:32 <sipa> grau: as there is some potential for ambiguity
1324 2013-02-24 17:21:53 <grau> I serialize the block using bitcoinj then count the length of bytes.
1325 2013-02-24 17:22:44 RatchetLove has quit (Ping timeout: 248 seconds)
1326 2013-02-24 17:23:04 <grau> gmaxwell: This is the blocktester https://code.google.com/r/bluemattme-bitcoinj/source/browse/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java?spec=svn874c5904b12d1fcec5b556429cf208f63cd4e1bc&name=fullverif&r=874c5904b12d1fcec5b556429cf208f63cd4e1bc
1327 2013-02-24 17:23:09 owowo has joined
1328 2013-02-24 17:23:52 <sipa> for example if the peer uses 0xFF + 8 bytes to send the tx count, but there are only 5 transactions, the size used to count against the limit would assume a single byte being used for the tx count only
1329 2013-02-24 17:23:53 <grau> gmaxwell: in lines 172-174 you see the use of ping to sync block send and its query
1330 2013-02-24 17:24:09 <gmaxwell> grau: do you pass if you just replace the ping seralization with a long delay?
1331 2013-02-24 17:24:29 <TD> grau: wow that code is using some really old crappy apis
1332 2013-02-24 17:24:49 <TD> grau: i really must merge that into bitcoinj master and update it to use the newer apis, that ping/pong code is just horrid
1333 2013-02-24 17:24:49 WeLoveCP has joined
1334 2013-02-24 17:24:50 <grau> TD: tell me where a newer is if there is one
1335 2013-02-24 17:24:58 <sipa> grau: i assume that is where the extra 8 bytes come from
1336 2013-02-24 17:25:10 <TD> no, i don't think there's a newer one. i'm just saying i should refresh it. like, you can wait for a ping/pong cycle now using futures
1337 2013-02-24 17:25:33 RatchetLove has joined
1338 2013-02-24 17:25:43 <grau> gmaxwell: I think it would be good to clean it up by TD or BlueMatt first
1339 2013-02-24 17:25:57 <grau> gmaxwell: I think such a crucial tool should be better
1340 2013-02-24 17:26:22 <TD> peer.ping().get();
1341 2013-02-24 17:26:22 <HM> TD: that's a cool technique, but not as cool as the proof that the x86 MMU is turing complete in its own right
1342 2013-02-24 17:26:36 <TD> HM: what, really?!
1343 2013-02-24 17:26:44 <gmaxwell> That isn't related to your code passing it or not!
1344 2013-02-24 17:27:02 <grau> HM: have you heard of wolframs rule 110, now that is turing complete :)
1345 2013-02-24 17:27:14 <gmaxwell> TD: you missed that? kinda pointless but: https://github.com/jbangert/trapcc
1346 2013-02-24 17:28:14 <TD> haha
1347 2013-02-24 17:28:29 <TD> well, i have to say i'm impressed. especially cool as i have an interest in code obfuscation
1348 2013-02-24 17:28:31 <gmaxwell> they show how to make the mmu perform a move,branch-if-zero,decrement (canonical single instruction turing machine) without any instructions getting executed.  Mostly useful for breaking emulators. :P
1349 2013-02-24 17:28:47 <HM> TD: original presentation watchable here: https://www.youtube.com/watch?v=NGXvJ1GKBKM
1350 2013-02-24 17:28:50 <TD> thanks
1351 2013-02-24 17:29:12 <HM> there's a lot of research by some security guys in to 'weird machines' atm
1352 2013-02-24 17:29:20 <TD> i wrote a code obfuscation engine for javascript as part of an anti-spam project at work
1353 2013-02-24 17:29:22 <HM> finding turing complete execution where people didn't know it existed
1354 2013-02-24 17:29:56 <TD> yeah, i must say i'd never have thought that the mmu might have been abusable in that way
1355 2013-02-24 17:30:30 <TD> the TRESOR paper is neat also (linked from mccunes paper). they show how to store an AES key in the debug registers and then use it, so it never hits memory at all and can't be found using cold boot attacks or bus snooping
1356 2013-02-24 17:30:43 <gmaxwell> grau: mostly I just asked that question to determine if the issue was really ping seralization. blocktester should probably be changed to use two connections and listen for relaying and use timeouts rather than depending on ping serialization.
1357 2013-02-24 17:31:21 <gmaxwell> TD: I'd seen prior aes key pinning that required effectively disabling the cache... not so hot for performance, alas.
1358 2013-02-24 17:32:11 <TD> yes. the debug register approach seems like it'd have less performance impact, though unfortunately, they have to regenerate round keys each time, so the raw AES speed isn't as good as it can normally be
1359 2013-02-24 17:32:30 <TD> that said, if you write your software with cache pinning in mind i suspect it can be not too terrible
1360 2013-02-24 17:32:38 <TD> for running regular software, yes. that'd suck.
1361 2013-02-24 17:33:05 <petertodd> "Yo dawg, I put a turing machine in your turing machines tape machine!"
1362 2013-02-24 17:34:07 <TD> what i'd like to experiment with at some point is extending trustvisor to enable cache no-fill mode and then automatically do encryption/decryption on page faults
1363 2013-02-24 17:34:34 <TD> probably you can make it semi-transparent to an app that expects to run in such an environment
1364 2013-02-24 17:34:46 <TD> a project for 5 years from now, maybe. assuming i still care by then.
1365 2013-02-24 17:35:22 <petertodd> TD: There have been some projects to put secret keys in cache lines; could be of assistance to you.
1366 2013-02-24 17:41:47 <ainfo> sipa: look at this bitcoind API: "importprivkey <bitcoinprivkey> [label] Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a rescan is done, looking for existing transactions. "
1367 2013-02-24 17:41:59 <ainfo> sipa: so bitcoind can just take a privkey and generate the wallet out of it too?
1368 2013-02-24 17:47:55 <TD> petertodd: yeah there are a few papers on this topic. it's quite interesting. trusted computing is so underexplored it's sad
1369 2013-02-24 17:47:58 <TD> like most of cryptography i guess
1370 2013-02-24 17:48:51 <petertodd> Doesn't help that TPM, in particular remote attestation, has enormous opposition from the tech community, albeit for good reason.
1371 2013-02-24 17:49:15 <jaakkos> OpenBlockFile (fopen) fails because of too many open fails
1372 2013-02-24 17:49:26 <petertodd> I love how you could actually use secure, widespread, remote attestation to create decentralized digital currencies directly from scratch; emphasis on "secure"...
1373 2013-02-24 17:49:46 <TD> hal explored that topic with IBM hardware years ago, he called his system RPOW
1374 2013-02-24 17:50:01 <ainfo> td: what would be some uses of trusted computing that could be explored much frurther?
1375 2013-02-24 17:50:15 <TD> not really "good reasons" imho. people don't understand the tech. even if you accept the premise that DRM is inherently bad (which i don't, it's a dumb position) then there is the issue that no shipping TC platform has ever had all the pieces needed to actually build a DRM system
1376 2013-02-24 17:50:24 <TD> in particular, secure IO was never fully specced out.
1377 2013-02-24 17:50:24 <petertodd> TD: I know, that's why I said widespread...
1378 2013-02-24 17:50:27 <TD> let alone implemented
1379 2013-02-24 17:50:28 <TD> yeah
1380 2013-02-24 17:50:48 <sipa> ainfo: yes
1381 2013-02-24 17:50:55 <TD> ainfo: it has tons of uses because it's so general. basically it lets a computer "prove" what it's running to a third party.
1382 2013-02-24 17:51:05 <ainfo> petertodd: how?
1383 2013-02-24 17:51:12 <TD> ainfo: so that third party can gain some assurances about how that computer will behave, ie, that it'll follow the rules it says it will.
1384 2013-02-24 17:51:14 <petertodd> Other than the IBM and Sun/Cisco stuff I don't know of any remote attestable hardware actually out there; the PC stuff doesn't support it at all.
1385 2013-02-24 17:51:24 <TD> ainfo: consider gmaxwells ideas about autonomous agents - http://en.bitcoin.it/wiki/Agents
1386 2013-02-24 17:51:32 <HM>  uint256 left = CalcHash(height-1, pos*2, vTxid), right;
1387 2013-02-24 17:51:32 <ainfo> td: you mean, prove it's actually doing a particular thing and not something else, so you could prove autehnticity of a computation result or sth?
1388 2013-02-24 17:51:34 <TD> ainfo: it becomes a LOT easier to write Agents if you have TC platforms available
1389 2013-02-24 17:51:35 <HM> eeep
1390 2013-02-24 17:51:42 <TD> ainfo: it can prove what software it's running
1391 2013-02-24 17:51:49 <TD> petertodd: sure it does.
1392 2013-02-24 17:51:59 <TD> petertodd: intel TXT+TPM can do remote attestation
1393 2013-02-24 17:52:02 <petertodd> BTW, re: tracing GHz bus-lines, it's a lot easier than you'd think: A: slow down the busses with overclocking tools, B: build some custom hardware directly onto the motherboard with your microscope to split the signals.
1394 2013-02-24 17:52:08 <ainfo> sipa: pubkey can be generated from privkey - aha
1395 2013-02-24 17:52:20 <TD> petertodd: and lots of regular intel boxes actually support all the required bits. some don't but many do.
1396 2013-02-24 17:52:29 <petertodd> TD: Only if the motherboard supports it, and none support it in a way that can be *duplicated*
1397 2013-02-24 17:52:32 <TD> as long as you're careful with the dell shop you can get yourself RA capable hardware fairly easily.
1398 2013-02-24 17:52:34 <ainfo> all the RPC handlign code in BitcoinD looks so thread-unsafe - are they run sequentially all of them and that's why it's written like this?
1399 2013-02-24 17:52:43 <ainfo> (not thread-unsafe, i meant, non-concurrent)
1400 2013-02-24 17:52:52 <petertodd> TD: You need control over bios versions and a tonne of other stuff that makes it impractical for anything but a single shop.
1401 2013-02-24 17:52:55 <HM> petertodd: at 29C3 there was a video presentation about grinding down chips and probing them with tweezers. surprisingly feasible on the cheap for slowish chips
1402 2013-02-24 17:53:24 <TD> petertodd: oh, sure, you can't write a regular downloadable app that my mother would run and make it do RA. but if you buy your own hardware you can make it do RA without needing anything too exotic.
1403 2013-02-24 17:53:26 <petertodd> HM: yup, there's a lot of clever tricks out there, although they don't apply to really dense chips, like Intel CPU's.
1404 2013-02-24 17:53:45 <TD> well the BIOS has to be the latest version, normally
1405 2013-02-24 17:53:50 <HM> Intel put amusing logos and watermarks in the layout of their transistors
1406 2013-02-24 17:53:53 <HM> probably still do
1407 2013-02-24 17:53:53 <petertodd> TD: Yes, but that's worthless for the digital currency case where someone else needs to duplicate the whole setup to audit your code.
1408 2013-02-24 17:54:02 <petertodd> HM: everyone does that
1409 2013-02-24 17:54:28 <petertodd> http://micro.magnet.fsu.edu/creatures/ <- the silicon zoo
1410 2013-02-24 17:54:47 etotheipi_ has joined
1411 2013-02-24 17:54:52 <HM> so brilliant
1412 2013-02-24 17:55:03 <TD> petertodd: why? just order the same off-the-shelf hardware, make sure you have the same BIOS and TXT SINIT module
1413 2013-02-24 17:55:17 <TD> but the point of RA is you don't need to duplicate the exact setup (though it might help improve your confidence)
1414 2013-02-24 17:55:36 <TD> you can check the signatures on the attestation and "know" that it came from a particular setup
1415 2013-02-24 17:55:50 <TD> (assuming you trust the whole hardware shebang of course)
1416 2013-02-24 17:56:22 <TD> iirc a remote attestation can be checked by more or less any device. don't _think_ you need a TPM to check it
1417 2013-02-24 17:56:29 <petertodd> TD: As I say, it has to be easy enough that you'll get a community of people actually doing that, to the point where others trust the various audits that have been done.
1418 2013-02-24 17:56:33 <TD> yeah
1419 2013-02-24 17:56:48 <TD> one idea i had for a business is to run a hosting provider that has a colo with some TC capable hardware
1420 2013-02-24 17:56:49 <petertodd> TD: Sure the attestation can be checked, but you can't really check it without audits.
1421 2013-02-24 17:57:05 <etotheipi_> petertodd:  "Frankly it bothers me that etotheipi hasn't realized that merkle sums are useful, or that people will make to make proofs out of this stuff."   Can you post about that in the UBC thread?  it sounds like something I should understand/take-into-account
1422 2013-02-24 17:57:06 <petertodd> TC + tor would be awesome...
1423 2013-02-24 17:57:08 <TD> and then people who want to use that technology can rent a secure VM on one of those machines
1424 2013-02-24 17:57:19 <TD> yeah. you'd end up with colo machines where the colo operators had no way to know what their own hardware was doing
1425 2013-02-24 17:57:24 <TD> (if implemented properly which is complicated)
1426 2013-02-24 17:57:35 <petertodd> etotheipi_: https://bitcointalk.org/index.php?topic=137933.0 here you go
1427 2013-02-24 17:57:55 <TD> obv yes, the software stack has to be audited for an RA to give confidence. that's ok though. once the initial version is audited you can just review all the diffs. and well-written TC software is supposed to be as tiny as possible anyway
1428 2013-02-24 17:58:05 <petertodd> etotheipi_: I mean, don't get me wrong, you've come up with a lot of cool ideas, it's just that you obviously haven't thought that hard about actually using them in the real world. :P
1429 2013-02-24 17:58:23 <petertodd> etotheipi_: I've done the exact opposite.
1430 2013-02-24 17:58:48 <etotheipi_> petertodd: I'm not offended... I'm just curious
1431 2013-02-24 17:59:01 <etotheipi_> I didn't know what you meant by "merkle sums"
1432 2013-02-24 17:59:19 <TD> that's not a term i've seen before either
1433 2013-02-24 17:59:27 <petertodd> hmm... Actually reviewing the diffs is very clever aproach. You could come up with a universal standard "do nothing" core, and then build upon that.
1434 2013-02-24 17:59:43 <petertodd> The audit would be that void main(){} matches basically.
1435 2013-02-24 18:00:09 <TD> yeah
1436 2013-02-24 18:00:20 <petertodd> Works because the TPM's hash registers work as chains of hashes, so the hash added to the chain is purely of software in a small domain, not a large one.
1437 2013-02-24 18:00:23 <TD> the general goal with TC is you build it up in layers
1438 2013-02-24 18:00:36 <petertodd> Yup
1439 2013-02-24 18:00:38 <TD> you start with a hypervisor that separates the trusted from untrusted realms and make it as small/tiny/auditable as possible
1440 2013-02-24 18:00:57 <petertodd> The PCR registers basically
1441 2013-02-24 18:01:02 <TD> then you have the code you want to prove running on top. but nothing stops you from having your provable/secure code itself be a little microkernel that imposes restrictions on the code it runs
1442 2013-02-24 18:01:15 <amiller> etotheipi_, a while ago i got you to agree that my version of the "goals" for UTXO commitment were somewhat stronger and more useful than the ones you had in mind when writing UBC
1443 2013-02-24 18:01:24 <TD> well, you only need to prove the bottom-most layers with the PCRs. then you can just make sure the bottom layers only run code that hashes to a certain value in software
1444 2013-02-24 18:01:26 <amiller> could we recap that?
1445 2013-02-24 18:01:35 <petertodd> etotheipi_: Merkle sum's are gmaxwell's term.
1446 2013-02-24 18:01:35 <TD> it's much faster than going back to the TPM
1447 2013-02-24 18:01:44 <amiller> because merkle sums are kind of a general concept that makes it easy to see how new functionality can be added to a committed data structure
1448 2013-02-24 18:02:23 <etotheipi_> amiller: you convinced me you were solving a problem out of scope for my solution ... I wouldn't want to use a design that isn't extensible to good ideas, but I also did not understand at all how you were going to get to those goals
1449 2013-02-24 18:02:39 <petertodd> TD: Alright, I think, hopefully, I can take back my statements on remote attestation being useless on commercial hardware, at least if L2 cache for storage can be solved.
1450 2013-02-24 18:02:47 <etotheipi_> amiller: or whether those goals we pipe dreams
1451 2013-02-24 18:02:56 <petertodd> TD: Probing the bus is easy, probing the inside of a 20nm chip is a nightmare.
1452 2013-02-24 18:03:00 <amiller> etotheipi_, the scope of the goals in either case possibly isn't so clear so we should clarify some of those
1453 2013-02-24 18:03:14 <etotheipi_> (no offense, but I couldn't tell if you speaking theoretically, or with intention to do it)
1454 2013-02-24 18:03:19 <amiller> i describe my goals as Full-Validation for light clients that only have O(1) storage
1455 2013-02-24 18:03:32 <amiller> etotheipi_, no i'm damn serious i'm also the only person who even has a toy implementation of a nontrivial merkle tree
1456 2013-02-24 18:03:38 <amiller> you're falling behind!
1457 2013-02-24 18:03:43 <TD> petertodd: yeah, i did some research this afternoon after reading your post. this seems like the most useful page: http://frozencache.blogspot.ch/
1458 2013-02-24 18:03:59 <TD> most of the research that's out there goes further than a TC system would need actually because it's so focused on full-disk encryption
1459 2013-02-24 18:04:00 <amiller> why settle for some confusing semi-trust security model when you can have full validation for the same effort?
1460 2013-02-24 18:04:20 <TD> petertodd: so it seems like it's at least possible, albiet not well explored in that specific context.
1461 2013-02-24 18:04:23 <petertodd> TD: yup, that's exactly the link I was trying to find for you.
1462 2013-02-24 18:04:50 <petertodd> TD: Fidelity-banks are kinda nice, because the vast majority of the data just needs to be authenticated, not secret.
1463 2013-02-24 18:04:54 <gmaxwell> amiller: on a total tangent, it seems UTXO expiration is surprisingly costly to support in the context of a merkle-tree-UTXO system.
1464 2013-02-24 18:05:07 <amiller> gmaxwell, nope i have a good solution for that
1465 2013-02-24 18:05:10 <etotheipi_> amiller: unfortunately, I have a lot of work to do with Armory... which I believe is also going to be valuable to Bitcoin, but more-time-critical (for me)
1466 2013-02-24 18:05:12 <amiller> gmaxwell, committed priority queue
1467 2013-02-24 18:05:41 <etotheipi_> amiller: so unfortunately, I have to table this for a couple more months (hopefully not forever)
1468 2013-02-24 18:06:23 <petertodd> etotheipi_: I at least need UTXO eventually for fidelity banks, so it's on my todo list too.
1469 2013-02-24 18:06:32 <amiller> etotheipi_, no worries, this is a somewhat long term goal for me
1470 2013-02-24 18:06:40 <amiller> etotheipi_, but i would appreciate it at a high level if we could agree on what the goals are
1471 2013-02-24 18:06:50 <etotheipi_> it's definitely a long-term interest for me
1472 2013-02-24 18:07:06 <TD> i liked the idea someone (can't remember who) came up with for networks of nodes that set up micropayment channels between them
1473 2013-02-24 18:07:16 <petertodd> amiller: I'm updating the wiki with a bunch of stuff today, so I'll create a UTXO page too
1474 2013-02-24 18:07:24 <TD> you'd deposit some money with them and then they'd adjust the contracts between themselves to move the value "instantly" in a low trust manner
1475 2013-02-24 18:07:38 <TD> legally, i think they'd probably be far enough away from banks that they might be able to avoid the worst problems
1476 2013-02-24 18:07:39 <petertodd> Reminds me, what are we going to call this feature exactly? UTXO Proofs?
1477 2013-02-24 18:07:54 nono has joined
1478 2013-02-24 18:07:56 <etotheipi_> petertodd: thanks for carrying the non-insert-order-dependent-data-structure torch for me... I've grown weary of arguing for it :)
1479 2013-02-24 18:08:29 <petertodd> etotheipi_: Ha, well, I'm carrying it because I'm not a comp-sci major and I can understand radix trees. :P
1480 2013-02-24 18:08:51 <petertodd> TD: I'm unconvinced about legality arguments in the long run; the law gets changed. In the short run though you're probably right.
1481 2013-02-24 18:09:09 <amiller> (fortunately this issue of tries vs deterministically balanced binary trees is mostly orthogonal to the better questions about the goals and general techniques!)
1482 2013-02-24 18:09:21 <petertodd> amiller: Yes, goals first!
1483 2013-02-24 18:09:21 Belkaar has quit (Ping timeout: 264 seconds)
1484 2013-02-24 18:09:25 <etotheipi_> petertodd: well I'm not a comp-sci major either, but I'm quite confident that being able to communicate compact UTXO sets is crucial for the future
1485 2013-02-24 18:09:39 <petertodd> etotheipi_: Ah, what major are you?
1486 2013-02-24 18:09:46 <etotheipi_> Applied Math
1487 2013-02-24 18:09:58 <etotheipi_> *was
1488 2013-02-24 18:10:02 Belkaar has joined
1489 2013-02-24 18:10:03 <etotheipi_> I've been out of school for a few years
1490 2013-02-24 18:10:41 <etotheipi_> BS Math, BS Mech Engineering, MS Applied & Computational Math
1491 2013-02-24 18:11:06 <etotheipi_> I just happened to have learned how to program along the way
1492 2013-02-24 18:11:26 <petertodd> etotheipi_: With that much math basic comp-sci is easy enough to learn.
1493 2013-02-24 18:11:32 <etotheipi_> and somehow, despite that focus, my "Data Structures" class (taken as an elective in undergrad) was one of my favorite classes
1494 2013-02-24 18:11:46 <amiller> etotheipi_, my goals are simple - full validation is really crucial to bitcoin, so verifiers should be made as simple as possible.  So my goal with UTXOs is full-validation that requires only O(1) storage on the verifier
1495 2013-02-24 18:12:04 <amiller> this means that even lite clients can be full validators
1496 2013-02-24 18:12:05 <petertodd> etotheipi_: Ha, nice, yeah, data structures are neat.
1497 2013-02-24 18:12:41 <petertodd> amiller: Well, not just verifiers, but also fraud proofs via UTXO; need to be explicit about that goal.
1498 2013-02-24 18:12:44 <amiller> if i understand your ubc post correctly your goals were somewhat less in scope and mostly involved convenience for SPV clients that don't validate anyway
1499 2013-02-24 18:12:51 * TD afk
1500 2013-02-24 18:13:17 <etotheipi_> amiller: I acknowledge what your goal is, my problem is that my brain doesn't have the wingspan at the moment to understand just how feasible that is
1501 2013-02-24 18:13:36 <etotheipi_> or rather, I haven't put much thought into it yet -- it sounds hard and fraught with danger
1502 2013-02-24 18:13:47 <etotheipi_> it may not be, I just can't get my brain around it
1503 2013-02-24 18:14:06 da2ce7 has joined
1504 2013-02-24 18:14:07 RBecker is now known as rbecker
1505 2013-02-24 18:14:09 <amiller> it's not, it doesn't even require a different structure than the tries you suggested
1506 2013-02-24 18:14:09 <etotheipi_> but if you put together a nice, articulated forum post (in the UBC thread, or a new thread), I'll happily read it and try to grok it
1507 2013-02-24 18:14:24 <gmaxwell> amiller: sure I cam up with using a minheap too, but then you need a seperate datastructure over all the utxo just to maintain the expiration, thats what I thought was expensive. You could also carry around max(height) values in your RB tree, and force any update to prune expired branches they update.
1508 2013-02-24 18:14:42 <HM> why would utxo want to expire?
1509 2013-02-24 18:14:56 <jaakkos> is there a sensible reason why getrawtransaction would fail even if the transaction most certainly exists?
1510 2013-02-24 18:14:56 <sipa> amiller: with O(1) storage, you basically turn every tx entry read/write that used to be constant time local operation into a O(log n) remote operation
1511 2013-02-24 18:15:08 <amiller> HM, it's a hypothetical way of regaining space if someone loses their key but it's kind of a distant gazing idea
1512 2013-02-24 18:15:09 <petertodd> jaakkos: you just upgraded to 0.8?
1513 2013-02-24 18:15:14 <sipa> jaakkos: if you're running 0.8 and don't have a txindex
1514 2013-02-24 18:15:28 <jaakkos> alright. but some transactions can still be found?
1515 2013-02-24 18:15:36 <sipa> jaakkos: unspent ones can still be found, yes
1516 2013-02-24 18:15:36 <etotheipi_> sipa: did you see my comment about circular buffers for seed generation?
1517 2013-02-24 18:15:46 da2ce7_d has quit (Ping timeout: 256 seconds)
1518 2013-02-24 18:15:53 <HM> sipa: "O(log n) remote operation" sounds like....oh nm, I won't say it :P
1519 2013-02-24 18:15:56 <sipa> etotheipi_: yeah, haven't had the time to think about the effects
1520 2013-02-24 18:16:09 <etotheipi_> sipa: no worries, I just wanted to know if you'd seen it
1521 2013-02-24 18:16:13 <jaakkos> alright, thanks
1522 2013-02-24 18:16:36 <sipa> jaakkos: run with -txindex -reindex once, if you want to be able to use getrawtransaction for arbitrary input
1523 2013-02-24 18:16:42 <jaakkos> how heavy is that
1524 2013-02-24 18:16:55 <etotheipi_> it's fairly simple... you can dramatically speed up the search time by maintaining a circular buffer of the sequential hashes...
1525 2013-02-24 18:17:11 <etotheipi_> so search time should go from 2^(2N) to 2^N
1526 2013-02-24 18:17:25 <sipa> jaakkos: 500 MiB extra storage, some mild processing overhead, and inability to prune in the future
1527 2013-02-24 18:17:29 <petertodd> ooh... speaking of seed gen... So maybe I just re-invented these circular buffers, but if you want a random number generated from block hashes or whatever, and the number is such that lsbs or whatever are most important, add the lsb of each block has to the msb of your seed, and shift right each time. By the time the bit matters, it'll be 256 blocks in.
1528 2013-02-24 18:17:30 <jaakkos> ok
1529 2013-02-24 18:17:54 <sipa> etotheipi_: yes, but doesn't it have an impact on the search time needed for an attacker either/
1530 2013-02-24 18:18:00 <petertodd> sipa: As CEO of Western Digital, I approve of txindex=1
1531 2013-02-24 18:18:10 <etotheipi_> sipa: I'm actually not clear on that myself, despite my statistics background
1532 2013-02-24 18:18:53 <petertodd> The idea would work well for lottery stuff, where people place <x bets.
1533 2013-02-24 18:19:07 <sipa> etotheipi_: and if it's just the factor 4 between any two difficulties that is the problem, the 'advanced' version with arbitrary constants fixes that
1534 2013-02-24 18:19:10 <HM> etotheipi_: what's this "seed generation" thing?
1535 2013-02-24 18:19:16 <petertodd> The amount of mining power needed to influence the bet goes up exponentially.
1536 2013-02-24 18:19:40 <etotheipi_> HM: it's what we were talking about yesterday
1537 2013-02-24 18:19:44 <sipa> HM: https://bitcointalk.org/index.php?topic=102349.0
1538 2013-02-24 18:20:03 <etotheipi_> sipa: for searching the 128-bit space, you're right, they get an advantage
1539 2013-02-24 18:20:15 <etotheipi_> or rather ,the attacker gets the same advantage as the computer generating the seed
1540 2013-02-24 18:20:26 <etotheipi_> but we've already assumed that searching 128-bit seedspace is infeasible
1541 2013-02-24 18:20:32 <HM> right, and it didn't make any sense to me :P
1542 2013-02-24 18:20:55 <sipa> etotheipi_: i don't really care about that - it just says that the reduction in keyspace is compensated for
1543 2013-02-24 18:21:25 <sipa> etotheipi_: can you elaborate, by the way, exactly which checks you'd do at which point?
1544 2013-02-24 18:21:52 <etotheipi_> sipa: my point is, that for an attacker searching through "low-entropy" seeds (possibly generated by a human), they'd still have to do the 2^N for each guess
1545 2013-02-24 18:21:56 <sipa> i'm not actually sure i got the gist of it
1546 2013-02-24 18:21:57 nus- has joined
1547 2013-02-24 18:22:12 nus has quit (Read error: Connection reset by peer)
1548 2013-02-24 18:22:45 TD has quit (Read error: Connection reset by peer)
1549 2013-02-24 18:22:47 da2ce7 has quit (Ping timeout: 252 seconds)
1550 2013-02-24 18:23:16 nono has quit (Quit: Page closed)
1551 2013-02-24 18:23:19 <etotheipi_> sipa: N=16, so looking for a seed that has 16 bits after 65536 hashes -- create a circular buffer of 65k*32bytes, and store the hash sequence in it... keep hashing until you find a value with 16 leading zero bits... then go back to the beginning of the buffer and that's your seed
1552 2013-02-24 18:23:38 <sipa> how do you know N=16 in advance?
1553 2013-02-24 18:23:38 <etotheipi_> that's where I'm starting from
1554 2013-02-24 18:23:46 <sipa> when decoding
1555 2013-02-24 18:24:02 <etotheipi_> sipa: oh right, I forgot we were using a variable number
1556 2013-02-24 18:24:06 TD has joined
1557 2013-02-24 18:24:10 da2ce7 has joined
1558 2013-02-24 18:24:11 <etotheipi_> either way, you use maximum N
1559 2013-02-24 18:24:25 <etotheipi_> if you find one that satisfies N=13, just go back 2^13 values in your buffer
1560 2013-02-24 18:24:44 <sipa> oh, this is just for generation
1561 2013-02-24 18:24:52 <etotheipi_> sipa, yes
1562 2013-02-24 18:24:57 <sipa> right, you're basically pipelining 2^N seed check operations
1563 2013-02-24 18:25:11 <etotheipi_> because we'd like to use large values of N, but we don't want to have the user wait 2.5 hours while looking for a good seed
1564 2013-02-24 18:25:18 <HM> etotheipi_: so "seed" is basically a counter or the result of some other deterministic permutation?
1565 2013-02-24 18:25:46 <sipa> etotheipi_: but that doesn't help if you want a human readable seed
1566 2013-02-24 18:26:09 <etotheipi_> sipa: I thought the point of this was to avoid human-readable seeds
1567 2013-02-24 18:26:16 <sipa> eh?
1568 2013-02-24 18:26:29 <sipa> i want to avoid human-generated seeds
1569 2013-02-24 18:27:12 <etotheipi_> why can't we just use binary seed data (base-256) and convert it into (base-something-else-with-human-readable-alphabet)?
1570 2013-02-24 18:27:24 <sipa> so, that's human readable
1571 2013-02-24 18:27:34 <sipa> right, i see the difference
1572 2013-02-24 18:27:46 idstam has quit ()
1573 2013-02-24 18:27:46 <sipa> i intended to just start directly from the human readable form
1574 2013-02-24 18:27:57 * HM still thinks using the users passphrase as a seed for the PRNG in vanitygen and looking for a random prefix would do the job, since the user should know the address they're trying to access anyway and therefore doesn't have to remember it
1575 2013-02-24 18:28:10 <sipa> so implementations can use any wordlist/character encoding/... they like, but still be interoperable
1576 2013-02-24 18:28:48 TD has quit (Ping timeout: 276 seconds)
1577 2013-02-24 18:29:03 <sipa> but you can see the encoding to/from human readable form as an additional step, and do the seed derivation on some binary data
1578 2013-02-24 18:29:10 da2ce7 has quit (Ping timeout: 246 seconds)
1579 2013-02-24 18:29:18 <etotheipi_> sipa: exactly
1580 2013-02-24 18:29:33 <etotheipi_> sipa: I'm fairly certain there's no disadvantage to that
1581 2013-02-24 18:29:34 <sipa> however, there's two other problems with it: it requires the hash function output to be the same size as the seed
1582 2013-02-24 18:29:46 <sipa> etotheipi_: there it, it requires standardizing the encoding!
1583 2013-02-24 18:30:00 <sipa> the cool thing about this proposal was exactly that it doesn't
1584 2013-02-24 18:30:03 <etotheipi_> sipa: there is no standard yet, though
1585 2013-02-24 18:30:08 <sipa> without compromising security
1586 2013-02-24 18:30:44 <sipa> and it also requires the hashing operations to be identical
1587 2013-02-24 18:31:08 <sipa> now, if the generator doesn't use this idea of yours, it may mean that an attacker could
1588 2013-02-24 18:31:27 <sipa> giving the attacker an advantage over the generation, which you certainly don't want
1589 2013-02-24 18:31:38 <sipa> so either give it to both, or make it impossible for both
1590 2013-02-24 18:31:47 <etotheipi_> sipa: how so?  you're still giving the user 128 bits of entropy
1591 2013-02-24 18:31:49 * sipa is inclined to prefer the second
1592 2013-02-24 18:32:15 <sipa> wait, i'm confusing things
1593 2013-02-24 18:32:27 <sipa> that's only a problem if the initial hashing step isn't part of the seeding
1594 2013-02-24 18:32:55 <sipa> thing is: i don't want to specify a seed needs to be N bits, and i don't want to specify what format it should be in
1595 2013-02-24 18:33:17 <sipa> a seed is simply a piece of text, and the algorithm takes care of both security and encoding its iterations
1596 2013-02-24 18:33:24 <etotheipi_> sipa: fair enough
1597 2013-02-24 18:33:41 <etotheipi_> it was just a thought I had, which seemed to be a feasible alternative to what we had come up with
1598 2013-02-24 18:33:44 <etotheipi_> I was curious what you thought of it
1599 2013-02-24 18:34:02 <sipa> well it is very interesting you thought about it
1600 2013-02-24 18:34:17 <etotheipi_> I hadn't considered that we *wouldn't* be generating the seeds as raw binary data
1601 2013-02-24 18:34:42 <sipa> as it means we can make it impossible for an attacker to exploit this trick
1602 2013-02-24 18:34:44 <etotheipi_> and I do agree, that it's nice the seed has no requirements for structure
1603 2013-02-24 18:35:54 TD has joined
1604 2013-02-24 18:35:59 <etotheipi_> sipa: actually I see you're point more clearly -- without this trick, the user can easily pick whatever entropy level they want
1605 2013-02-24 18:36:57 <etotheipi_> all valid inputs to a hash function (any string) is a valid *potential* seed
1606 2013-02-24 18:37:22 <sipa> etotheipi_: i think in the demo version i wrote in JS, i use the iteration count as an input to the hash function
1607 2013-02-24 18:37:29 <sipa> making such pipelining impossible
1608 2013-02-24 18:37:56 <etotheipi_> sipa: gotcha
1609 2013-02-24 18:38:05 <etotheipi_> fair enough
1610 2013-02-24 18:39:02 <sipa> though i'd like to think about what security parameters you'd get when you do exploit this
1611 2013-02-24 18:39:02 <etotheipi_> quick question... is there a way to make Bitcoin-Qt/bitcoind drop its memory pool?
1612 2013-02-24 18:39:10 <sipa> etotheipi_: restart it :p
1613 2013-02-24 18:39:14 <etotheipi_> oh really?
1614 2013-02-24 18:39:27 <sipa> yes
1615 2013-02-24 18:39:31 <etotheipi_> I thought it kept the memory pool between loads
1616 2013-02-24 18:39:44 <sipa> it wouldn't really be a *memory* pool in that case :p
1617 2013-02-24 18:39:44 <etotheipi_> well that's easy!
1618 2013-02-24 18:40:00 <TD> it SHOULD keep it in between reloads :)
1619 2013-02-24 18:40:02 <TD> and on disk
1620 2013-02-24 18:40:04 <etotheipi_> sipa:  unlike my "mempool.bin" used by Armory
1621 2013-02-24 18:40:05 <TD> in a leveldb
1622 2013-02-24 18:40:24 <sipa> TD: eventually, yes
1623 2013-02-24 18:42:43 MobPhone has quit (Remote host closed the connection)
1624 2013-02-24 18:42:56 <gmaxwell> uh, not without a way to expire it, it shouldn't! :)
1625 2013-02-24 18:43:24 i2pRelay has joined
1626 2013-02-24 18:43:24 <sipa> it seems reasonable that at some point, mempools may need to grow beyond a point that fits easily on disk
1627 2013-02-24 18:43:29 <sipa> eh, easily in memory
1628 2013-02-24 18:44:03 <etotheipi_> how will super-future locked tx's be handled?
1629 2013-02-24 18:44:09 <sipa> but that brings you to the question how long transactions are supposed to stay there, and whether there needs to be a distinction between perhaps transactions that want to stay longer
1630 2013-02-24 18:44:20 <etotheipi_> sipa:  jinx!
1631 2013-02-24 18:44:44 <sipa> i guess an easy way would be to say that transactions needs to pay a fee to do so... the higher the fee/size, the longer it can stay
1632 2013-02-24 18:44:51 <etotheipi_> do we want to allow tx's with lock-times in 2050 to stick around forever
1633 2013-02-24 18:44:55 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
1634 2013-02-24 18:45:01 <etotheipi_> (well, stick around until 2050)
1635 2013-02-24 18:45:16 <TD> just have nodes use a configurable amount of disk space then delete them in reverse priority order
1636 2013-02-24 18:45:26 <TD> node operators can then decide how much they care
1637 2013-02-24 18:45:34 <sipa> once client-specified size constraints (whether it's on disk or in memory) are reached, delete those with the lowest fee/size
1638 2013-02-24 18:45:37 <sipa> yeah exactly
1639 2013-02-24 18:46:37 <sipa> the best definition for priority here may be a different one than for those entering blocks
1640 2013-02-24 18:47:01 <HM> etotheipi_: your gistfile1.txt gist which explains how you came up with the constants is very lengthy for a relatively simple calculation :|
1641 2013-02-24 18:47:09 MobPhone has joined
1642 2013-02-24 18:47:24 <etotheipi_> HM: link me
1643 2013-02-24 18:47:29 <etotheipi_> I don't know what you're talking about
1644 2013-02-24 18:47:32 <HM> https://gist.github.com/sipa/2731997
1645 2013-02-24 18:47:36 <sipa> as the memory pool is purely limited by size (its verification work is spent once, and independent from how long it remains in the mempool)
1646 2013-02-24 18:47:39 <HM> oh wait, that's sipas
1647 2013-02-24 18:47:41 <HM> :|
1648 2013-02-24 18:47:42 <sipa> HM: i did that calculation :)
1649 2013-02-24 18:47:55 <sipa> and i agree, but it results in very nice 2^N behaviour
1650 2013-02-24 18:48:02 <sipa> which is easy to verify
1651 2013-02-24 18:48:10 <etotheipi_> HM: although I do agree:  I still haven't wrapped my head around the calculation, though I understand what it does
1652 2013-02-24 18:48:48 <HM> but it's just  ln ((2^32 / k)*i) / ln 2 = 17,18,19,20 etc
1653 2013-02-24 18:49:09 <HM> arbitrarily chose increasing values of i and solve for k
1654 2013-02-24 18:49:28 <sipa> approximately, yes
1655 2013-02-24 18:49:32 <sipa> exactly, no :)
1656 2013-02-24 18:49:48 <HM> you have to take in to account the probability of the previous iterations
1657 2013-02-24 18:49:50 <HM> right
1658 2013-02-24 18:49:59 <HM> so the average is what you want
1659 2013-02-24 18:50:02 <HM> or something
1660 2013-02-24 18:50:18 <gmaxwell> I wonder if bluematt would find it more agreeable if priority = sum(uxto_bytes * age) / size    IOW, utxo-bytes-destroyed instead of coin-days, since he was so opposed to value staying as part of priority.
1661 2013-02-24 18:57:27 <HM> sipa: so, for i(1) the cost is 363 iterations but only (2^32 - 0x1010000) / 2^32 of the time. right?
1662 2013-02-24 18:57:28 da2ce7 has joined
1663 2013-02-24 18:57:42 <HM> so you adjusted for that
1664 2013-02-24 18:58:11 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1665 2013-02-24 18:59:32 <TD> gavinandresen: so coming any closer to a decision on the name?
1666 2013-02-24 19:07:48 Garr255A has joined
1667 2013-02-24 19:08:46 ralphtheninja has joined
1668 2013-02-24 19:11:05 cderivan has joined
1669 2013-02-24 19:11:42 Garr255 has quit (Ping timeout: 276 seconds)
1670 2013-02-24 19:12:45 tg has quit (Ping timeout: 245 seconds)
1671 2013-02-24 19:19:40 tg has joined
1672 2013-02-24 19:20:43 da2ce7 has quit (Ping timeout: 252 seconds)
1673 2013-02-24 19:21:29 da2ce7 has joined
1674 2013-02-24 19:24:21 Garr255A has quit (Read error: Connection reset by peer)
1675 2013-02-24 19:24:34 Z0rZ0rZ0r has joined
1676 2013-02-24 19:37:08 tg has quit (Read error: Connection reset by peer)
1677 2013-02-24 19:38:30 tg has joined
1678 2013-02-24 19:40:32 kirill42 has joined
1679 2013-02-24 19:42:49 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
1680 2013-02-24 19:43:35 LainZ has quit (Read error: No route to host)
1681 2013-02-24 19:46:20 zooko has joined
1682 2013-02-24 19:46:45 LainZ has joined
1683 2013-02-24 19:47:06 da2ce7_d has joined
1684 2013-02-24 19:47:59 da2ce7 has quit (Ping timeout: 260 seconds)
1685 2013-02-24 19:52:27 <ainfo> sipa: there's a importprivkey so bitcoind can do this  scanning for all transactions nowadays too?
1686 2013-02-24 19:52:40 <ainfo> as not to need a wallet.dat file
1687 2013-02-24 19:52:43 <ainfo> i mean, require
1688 2013-02-24 19:52:43 forloop has joined
1689 2013-02-24 19:53:18 <gmaxwell> somehow, I suspect this isn't quite accurate: 2013-02-24 19:33:34 Committing 30012 changed transactions to coin database...
1690 2013-02-24 19:53:43 <gmaxwell> ainfo: importprivkey takes about 10 minutes
1691 2013-02-24 19:54:24 da2ce7 has joined
1692 2013-02-24 19:54:45 <ainfo> gmaxwell: so it blocks the RPC caller for 10 minutes?
1693 2013-02-24 19:55:04 <ainfo> and all the RPC calls are made synchronously so it actually blocks all RPC access, right?
1694 2013-02-24 19:55:08 da2ce7_d has quit (Ping timeout: 255 seconds)
1695 2013-02-24 19:55:27 <ainfo> how easy is it to plug and unplug wallet.dat files?
1696 2013-02-24 19:55:38 <ainfo> as to take them to and back from "cold storage" or alike etc
1697 2013-02-24 19:55:54 <ainfo> i'd be happy to have lots of bitcoin addresses, though would be happy to keep them in a non-fragile format
1698 2013-02-24 19:56:08 <ainfo> wallet.dat as far as i know it is essentially a container for *all* the addresses
1699 2013-02-24 19:56:17 <ainfo> it it blows, i need to do that 10-minute import x 1000
1700 2013-02-24 19:56:21 <ainfo> it'd take half a year
1701 2013-02-24 19:56:31 <ainfo> how can i separate thingsd so that i get lots of redundancy?
1702 2013-02-24 19:56:46 tg has quit (Read error: Connection reset by peer)
1703 2013-02-24 19:56:55 balrog has quit (Read error: Connection reset by peer)
1704 2013-02-24 19:57:18 <ainfo> i guess i should better keep with bitcoind because all the other bitcoin implementations seem not completely mature
1705 2013-02-24 19:57:29 <ainfo> gmaxwell: any thought/suggestion?
1706 2013-02-24 19:57:47 <amiller> sipa, you made a claim that my suggested O(1) storage scheme requires many more operations than a standard data structure
1707 2013-02-24 19:58:17 <gmaxwell> ainfo: yes it blocks for the time it takes. It's perfectly easy to swap out wallet files, many people do so.
1708 2013-02-24 19:58:23 tg has joined
1709 2013-02-24 19:58:25 <amiller> i wanted to point out that a) there's lots of ways of improving the efficiency by making the best use of whatever storage the client happens to have, which might be the whole thing - and b) your point is true for etotheipi_ 's suggestions as well
1710 2013-02-24 19:58:46 <amiller> so that's not an argument for preferring his weaker goals than the stronger O(1)-any-client-can-verify goal
1711 2013-02-24 19:58:52 <gmaxwell> ainfo: we may gain the ability to mount and unmount files and run with multiple files..
1712 2013-02-24 19:59:33 <sipa> amiller: well, any UTXO tree implementation will change O(1) updates into O(log n) updates
1713 2013-02-24 19:59:33 TD has quit (Quit: TD)
1714 2013-02-24 19:59:41 <gmaxwell> amiller: I think he was just pointing out that storgeless isn't obviously super useful; I'm sure he was not advancing etotheipi's stuff over it.
1715 2013-02-24 19:59:57 <amiller> they're not really O(1) anyway unless it's so small it fits in ram
1716 2013-02-24 20:00:19 <BlueMatt> gmaxwell: yes, I would find that very agreeable
1717 2013-02-24 20:00:33 da2ce7_d has joined
1718 2013-02-24 20:00:51 <BlueMatt> gmaxwell: but, I wasnt /against/ value staying as a part of priority, only value being weighted after you get into larger values
1719 2013-02-24 20:01:02 <gmaxwell> BlueMatt: would anyone except you find it agreeable?  (I'm not sure if I do yet—  but I think it does actually meet the criteria for something we need in a priority scheme)
1720 2013-02-24 20:01:35 <BlueMatt> gmaxwell: probably not much, though I really need to go read some of the old writings before I really analyze it
1721 2013-02-24 20:01:38 <gmaxwell> BlueMatt: yes, but I was against that. Making it nonlinear encourages people to fragment their output just for the sake of appealing to the priority function gods. :P
1722 2013-02-24 20:01:41 <BlueMatt> (sorry its early, I just woke up)
1723 2013-02-24 20:01:52 <amiller> well at a high level (discussing goals rather than constructions) i think it's straightforward that making it easier to do full-validation is a fundamentally good thing but i don't know how to argue that
1724 2013-02-24 20:02:00 <ainfo> gmaxwell: so currently it's one only?
1725 2013-02-24 20:02:01 <BlueMatt> gmaxwell: I know...but we could so something logarithmic or something...
1726 2013-02-24 20:02:09 <gmaxwell> ainfo: yes.
1727 2013-02-24 20:02:09 da2ce7 has quit (Ping timeout: 252 seconds)
1728 2013-02-24 20:02:24 <BlueMatt> well...no I dont like logarithmic either...
1729 2013-02-24 20:02:26 <BlueMatt> anyway
1730 2013-02-24 20:02:43 <ainfo> gmaxwell: aha, so swapping in and out a wallet file, that's interesting. what's the effect of swapping? i mean, so say I have bitcoin addresses A-F in wallet G.H and addresses H-K in wallet file L
1731 2013-02-24 20:02:43 <gmaxwell> BlueMatt: log-linear is at least not so obviously borken, but dunno if it would do what you wanted.
1732 2013-02-24 20:03:22 <ainfo> gmaxwell: when i swap when I swap from G to L, then how fast do the balances of H-K get updated?
1733 2013-02-24 20:03:22 <gmaxwell> ainfo: they're just seperate wallets.
1734 2013-02-24 20:03:29 <ainfo> is it transparent or..?
1735 2013-02-24 20:03:53 <gmaxwell> it only rescans the time since the wallet was last used... usually unnoticable if you swap even vaguely often.
1736 2013-02-24 20:04:00 <sipa> ainfo: wallets remember which part of the block chain they have seen, and if the chain data is more up to date than the wallet, the missing part is rescanned at startup automatically
1737 2013-02-24 20:04:15 <ainfo> do you need to restart bitcoind in order to switch wallet?
1738 2013-02-24 20:04:17 <BlueMatt> gmaxwell: well, in any case it doesnt have to be non-linear, it can be some kind of "count fully at low values, count partially and phase out counting through a range, and then dont count at all above X" or similar
1739 2013-02-24 20:04:20 <sipa> ainfo: yes
1740 2013-02-24 20:04:25 tg has quit (Ping timeout: 245 seconds)
1741 2013-02-24 20:04:42 <BlueMatt> Luke-Jr: why is http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html not displaying right on chrome?
1742 2013-02-24 20:04:51 <BlueMatt> or ff
1743 2013-02-24 20:05:02 <gmaxwell> BlueMatt: thats still non-linear. ::sigh::
1744 2013-02-24 20:05:09 <ainfo> sipa: this scan happens before *any* access can be done with the RPC API or alike to the wallet?
1745 2013-02-24 20:05:19 <BlueMatt> gmaxwell: well, ok...anyway let me go do some reading
1746 2013-02-24 20:05:21 <sipa> ainfo: indeed
1747 2013-02-24 20:05:46 <Luke-Jr> BlueMatt: versions.txt is null
1748 2013-02-24 20:05:46 <ainfo> sipa: aha. just roughly what can bitcoind's start time and shutdown time be? you do like KILL -anicesignal,notkill/9! bitcoind or ??
1749 2013-02-24 20:05:56 <gmaxwell> BlueMatt: anything where the derivative of the function wrt something the user controls is not a constant is subject to gaming. e.g. where you make two outputs instead of one because f(x+y) != f(x)+f(y)
1750 2013-02-24 20:06:00 <ainfo> aha great so there is atomicity hm
1751 2013-02-24 20:06:27 <sipa> ainfo: not-fatal killing should be fine (sigterm or sigint or so)
1752 2013-02-24 20:06:50 <sipa> actually, just those two
1753 2013-02-24 20:07:08 <Luke-Jr> BlueMatt: fixed
1754 2013-02-24 20:07:17 <BlueMatt> Luke-Jr: thanks
1755 2013-02-24 20:07:22 <ainfo> aha
1756 2013-02-24 20:07:32 <Luke-Jr> sipa: any idea why dnsseed.dump might be null sometimes?
1757 2013-02-24 20:07:38 da2ce7 has joined
1758 2013-02-24 20:07:42 <Luke-Jr> like when my cronjob goes to update verisons.txt? <.,
1759 2013-02-24 20:07:46 <ainfo> about what startup and shutdown time might we be talking about? 0.1sec? 1sec? 10sec?
1760 2013-02-24 20:08:19 <gmaxwell> ainfo: I think at this point you'd get more out of trying things out yourself instead of asking all questions here. :)
1761 2013-02-24 20:08:44 <ainfo> hm yeah :)
1762 2013-02-24 20:08:44 <gmaxwell> it would take you less time to try that and get a 100% sure answer than it takes to ask us and have us maybe guess.
1763 2013-02-24 20:08:53 <gmaxwell> 0.8 at least should shutdown fast.
1764 2013-02-24 20:08:57 <ainfo> wait. i have like two more q:s first though :)
1765 2013-02-24 20:09:34 da2ce7_d has quit (Ping timeout: 260 seconds)
1766 2013-02-24 20:09:45 <BlueMatt> gmaxwell: ack...anyway what was the old algorithm that you were proposing that I hated so much?
1767 2013-02-24 20:09:54 <BlueMatt> or do you have it...before i go digging through logs
1768 2013-02-24 20:10:28 <ainfo> apart from bitcoind, could *any* other implementation be said to be reallys table for a full verified database? any at all?   bitcoinj sounds like the most stable but even that one says "experimental" for the whole verified thing
1769 2013-02-24 20:11:17 <sipa> Luke-Jr: yes; fix on the way
1770 2013-02-24 20:11:48 <gmaxwell> BlueMatt: sum(value*age)/α*max(size,2*size+utxo_change))  with α set to match up the current behavior, or something equal to that.
1771 2013-02-24 20:12:00 tg has joined
1772 2013-02-24 20:13:34 <gmaxwell> ainfo: 'stable' in what way?  That is a tricky question. Bitcoin-qt is correct by definition, everything else has to emulate any bugs bitcoin-qt has.
1773 2013-02-24 20:13:35 kirill42 has quit (Ping timeout: 245 seconds)
1774 2013-02-24 20:14:19 <sipa> Luke-Jr: potential fix pushed
1775 2013-02-24 20:14:41 <BlueMatt> gmaxwell: hmm...ok so I like the new suggestion, Im not sure if Im entirely for dropping value from the calculation entirely (I kinda feel like we need to further discourage sd-style 1-satoshi returns) but Im certainly not against the new suggestion
1776 2013-02-24 20:14:53 <Luke-Jr> ainfo: bitcoind itself is experimental
1777 2013-02-24 20:14:56 <Luke-Jr> all Bitcoin is
1778 2013-02-24 20:15:13 <ainfo> gmaxwell: =)  well, i mean, robust enough to expectably keep a blockchain locally up to date correctly, and to keep address balances correctly and not do or accept any bogus about incoming or outgoing transactions
1779 2013-02-24 20:15:36 <sipa> ainfo: bitcoin is a consensus network - it depends on every node implementing exactly the same consistent rules
1780 2013-02-24 20:15:38 <ainfo> yeah i know bitcoin is exterpimental, but the protocol is not beta at all, it's real stable; so what implementations can be considered stable?
1781 2013-02-24 20:15:41 X-Scale has quit (Ping timeout: 245 seconds)
1782 2013-02-24 20:16:11 <sipa> ainfo: which means that 'correct' is always 'what the network is running', and right now, i'm quite sure 99% of fully validating nodes are bitcoind/bitcoin-qt
1783 2013-02-24 20:16:15 <BlueMatt> ainfo: I want to say the bitcoinj fullverify stuff is perfect, but despite lots of testing it still gets the occasional bug...still it doesnt implement some of the new block v2 stuff etc
1784 2013-02-24 20:16:18 rabbit_ has joined
1785 2013-02-24 20:16:27 <rabbit_> hi
1786 2013-02-24 20:16:31 * Luke-Jr grumbles at sipa putting his personal CXXFLAGS in Makefile
1787 2013-02-24 20:17:09 <sipa> Luke-Jr: actually, i don't :)
1788 2013-02-24 20:17:12 <Luke-Jr> cc1plus: error: unrecognized command line option "-flto"
1789 2013-02-24 20:17:29 <ainfo> bluematt: what would the bug be?  migh tit ever trash the database file (blockchain or wallet) or perform incorrect transaction sends/receptions or report an incorrect balance or status?
1790 2013-02-24 20:17:29 <sipa> -march=native doesn't work for me, as it detects the architecture on my VPS wrong
1791 2013-02-24 20:17:36 <sipa> Luke-Jr: you need gcc 4.5 for that
1792 2013-02-24 20:17:45 <Luke-Jr> gcc (Gentoo 4.4.5 p1.3, pie-0.4.5) 4.4.5
1793 2013-02-24 20:18:09 <sipa> ainfo: bug as in "disagrees with the network, accidentally ends up on its own chain"
1794 2013-02-24 20:18:43 <sipa> Luke-Jr: i have no problem with pullreqs to make it more configurable :)
1795 2013-02-24 20:18:55 <Luke-Jr> sipa: it's configurable, I was just trolling the default
1796 2013-02-24 20:18:59 <ainfo> sipa: Ouch. well,, that's about as serious as it can go isn't it, because for every minutet hat proceeds there's like a problem building up?
1797 2013-02-24 20:19:10 OneMiner has quit (Quit: Clap on! , Clap off! Clap@#&$NO CARRIER)
1798 2013-02-24 20:19:13 <ainfo> so you'd need to go back and fix things and.. transactions end up invalid, no?
1799 2013-02-24 20:19:38 <BlueMatt> ainfo: there was a bug not long ago with the sighash options not being implemented quite right (fixed now) so it claimed some transactions where invalid that were
1800 2013-02-24 20:19:40 <rabbit_> the bitcoin-qt command "listaccounts" looks like a hash of labels and amounts -- is that what an "account" is?
1801 2013-02-24 20:19:57 <BlueMatt> ainfo: still, the majority of it is quite stable
1802 2013-02-24 20:20:01 <BlueMatt> (and tested)
1803 2013-02-24 20:20:05 <sipa> rabbit_: an account is a virtual balance
1804 2013-02-24 20:20:05 <forloop> Hello. When I want to reboot my MacBook, I first have to shut bitcoin-qt down.  The UI disappears, but the process hangs around for over 10min.  Does bitcoin-qt wait for the next block before it finally terminates?
1805 2013-02-24 20:20:20 <sipa> forloop: which version?
1806 2013-02-24 20:20:23 <Luke-Jr> forloop: this is 0.8?
1807 2013-02-24 20:20:36 nus- is now known as nus
1808 2013-02-24 20:20:40 <sipa> forloop: it's certainly not expected
1809 2013-02-24 20:20:57 <rabbit_> sipa: ah... that helps. thank you
1810 2013-02-24 20:21:33 <forloop> version 0.7.2
1811 2013-02-24 20:21:35 <gmaxwell> BlueMatt: well, I think that should be seperate from priority, instead what we should do is figure out what level of fee is effectively required by the recent chain and make outputs some fraction of that treated as non-standard.  Basically "don't create any output which will cost more to redeem than its worth".
1812 2013-02-24 20:21:54 B0g4r7 has quit (Ping timeout: 276 seconds)
1813 2013-02-24 20:22:00 da2ce7_d has joined
1814 2013-02-24 20:22:19 <sipa> rabbit_: an account has nothing to do with coin selection (all accounts in a wallet share the same coins); it just allows you to keep track of receives/sends in different categories
1815 2013-02-24 20:22:19 <BlueMatt> gmaxwell: Id certainly go for that
1816 2013-02-24 20:22:21 <Luke-Jr> forloop: do you have detachdb in a config somewhere?
1817 2013-02-24 20:22:44 <sipa> forloop: can you test whether 0.8 exhibits the same behaviour?
1818 2013-02-24 20:22:45 <forloop> Luke: no, stock installl
1819 2013-02-24 20:23:09 <petertodd> Quick question: what influences how big a signature is? I'm looking at minimum tx size, and sigs seem to be 71, 72, or 73 bytes. (or more?)
1820 2013-02-24 20:23:14 <gmaxwell> BlueMatt: the downside of that is that it would effectively be a dynamic limit and people _hate_ stuff that they can't easily predict.
1821 2013-02-24 20:23:29 <sipa> petertodd: 50% are 72, 25% are 71, 25% are 73 :)
1822 2013-02-24 20:23:37 <rabbit_> sipa: ah.. categories ty again!
1823 2013-02-24 20:23:48 <petertodd> sipa: Cool, and no other sizes are possible?
1824 2013-02-24 20:23:57 <ainfo> is there any finer-granularity switching mechanism than per wallet.db?  it's 130KB already when you start out without any btc addresses
1825 2013-02-24 20:24:04 <ainfo> like, backup a btc address' state into a byte array
1826 2013-02-24 20:24:09 da2ce7 has quit (Ping timeout: 260 seconds)
1827 2013-02-24 20:24:23 <sipa> petertodd: smaller ones are possible with exponentially smaller chance
1828 2013-02-24 20:24:34 <rabbit_> sipa: so is it through categories that one would create "multiple accounts" using a single bitcoin-qt instance?
1829 2013-02-24 20:24:43 <petertodd> sipa: Right, and I guess larger too then?
1830 2013-02-24 20:24:51 <sipa> petertodd: no, 73 is max
1831 2013-02-24 20:25:01 <rabbit_> sipa: I use "multiple accounts" not in any bitcoin sense, but in the sense that a single user may have more than one account with a bank
1832 2013-02-24 20:25:19 <sipa> rabbit_: it's very similar to that yes
1833 2013-02-24 20:25:26 <forloop> sipa: yes, I will.  I'll download later.
1834 2013-02-24 20:25:32 <sipa> though the abstraction is very thin, and confusing to many
1835 2013-02-24 20:25:34 <rabbit_> sipa: beautiful. thank you
1836 2013-02-24 20:25:35 <gmaxwell> petertodd: they are numbers mod the field size. if you get a signature whos value is 1 the data would be short indeed. Can't be larger than the field size.
1837 2013-02-24 20:26:01 OneMiner has joined
1838 2013-02-24 20:26:26 <petertodd> gmaxwell: Ah, varint encoded. I'm updating the wiki, so I'll just say 73 bytes max, 72 bytes avg, and smaller than that exponentially less likely.
1839 2013-02-24 20:26:27 <BlueMatt> gmaxwell: yea, I mean I kinda like the idea of putting /everything/ in priority and then doing it all based on that, still as long as clients are able to notify users of their txn being (potentially) nonstandard before it is sent....
1840 2013-02-24 20:26:29 nus- has joined
1841 2013-02-24 20:26:37 [\\\] has quit (Remote host closed the connection)
1842 2013-02-24 20:26:46 RazielZ has quit (Ping timeout: 246 seconds)
1843 2013-02-24 20:26:55 <sipa> petertodd: the 72/71/73 issue is because numbers that would normally start with their highest bit set, "should" get a 0 byte in front to disambiguate them from negative numbers
1844 2013-02-24 20:27:21 <sipa> petertodd: so 50% need 1 extra zero, 25% need no extra zero, 25% need two extra zeroes
1845 2013-02-24 20:27:43 <sipa> the exponentially smaller ones, are due to the first byte potentially actually being 0, so one byte less in necessary
1846 2013-02-24 20:28:02 <petertodd> sipa: Right, so you'd need 8 bits 0 to get 70 bytes.
1847 2013-02-24 20:28:24 <sipa> indeed
1848 2013-02-24 20:28:29 [\\\] has joined
1849 2013-02-24 20:28:35 <sipa> and neither number having their highest remaining bit set
1850 2013-02-24 20:29:06 <gmaxwell> BlueMatt: maybe, I mean I wrote out some math for combining multiple kinds of priority, kind of a soft_min with weights based on average transactions in the recent chain, but I decided that I'd never convince anyone else of it. It gets messy fast.
1851 2013-02-24 20:29:07 <jgarzik> "Identifi: The P2P Identity and Reputation Database"
1852 2013-02-24 20:29:11 * jgarzik wonders if it's worth anything
1853 2013-02-24 20:29:22 JDuke128 has joined
1854 2013-02-24 20:30:38 <rabbit_> when the docs refer to "client" and "node" are they the same thing?
1855 2013-02-24 20:30:44 B0g4r7 has joined
1856 2013-02-24 20:31:21 nus has quit (Ping timeout: 276 seconds)
1857 2013-02-24 20:31:29 <sipa> the client is the program, it implements a node in the bitcoin p2p network
1858 2013-02-24 20:31:51 <BlueMatt> gmaxwell: yea, I think complexity here is definitely not good
1859 2013-02-24 20:32:17 <rabbit_> ty!
1860 2013-02-24 20:35:23 <rabbit_> when creating a transaction using createrawtransaction, how does one get the transaction key to place as argument to the function?
1861 2013-02-24 20:35:46 <sipa> use getrawtransaction or listunspent
1862 2013-02-24 20:38:00 <rabbit_> sipa: so... all "new transactions" refer to a previous transaction?
1863 2013-02-24 20:38:45 <sipa> every transaction refers to the previous outputs it spends, so yes
1864 2013-02-24 20:40:15 sacredchao has quit (Remote host closed the connection)
1865 2013-02-24 20:41:19 <HM> i hate reading papers
1866 2013-02-24 20:41:55 sacredchao has joined
1867 2013-02-24 20:41:56 <HM> sometimes take longer to parse and read than to understand
1868 2013-02-24 20:42:57 <rabbit_> sipa: when you say "outputs" are you referring to the structures yielded by listunspent ? (those being "transactions" ?)
1869 2013-02-24 20:43:07 datagutt has quit (Quit: kthxbai)
1870 2013-02-24 20:43:09 <sipa> rabbit_: read up how bitcoin transactions work
1871 2013-02-24 20:43:29 <sipa> rabbit_: a transaction consumes coins, and creates new coins
1872 2013-02-24 20:43:35 <sipa> a coin being an unspent transaction output
1873 2013-02-24 20:43:36 TD has joined
1874 2013-02-24 20:43:44 <sipa> identified by a transaction id, and an output number
1875 2013-02-24 20:44:11 <BlueMatt> gmaxwell: actually, thinking about it a bit more, Id go for a relatively high-base logarithm on value using the original formula
1876 2013-02-24 20:44:14 <rabbit_> sipa: will do. thank you for your help :)
1877 2013-02-24 20:44:26 <BlueMatt> gmaxwell: (wow...probably should have come around to that idea months ago...sorry)
1878 2013-02-24 20:44:52 HiroWhite has quit (Ping timeout: 260 seconds)
1879 2013-02-24 20:45:09 <sipa> Q: how many signature checks does test_bitcoin in git head do
1880 2013-02-24 20:45:35 <sipa> A: 1332
1881 2013-02-24 20:47:12 daybyter has quit (Quit: Konversation terminated!)
1882 2013-02-24 20:47:18 WolfAlex has joined
1883 2013-02-24 20:47:41 ThomasV has joined
1884 2013-02-24 20:47:58 <HM> sipa: 1337 would have been more l33t
1885 2013-02-24 20:48:11 <BlueMatt> HM: so go add 5 more :)
1886 2013-02-24 20:48:33 <sipa> BlueMatt: hmm, i have actually never looked into bitcoin-qt's test
1887 2013-02-24 20:48:41 <sipa> how do i build it, and what does it test?
1888 2013-02-24 20:49:02 <BlueMatt> sipa: I dont remember how to build it, and it only tests the bitcoin: uri handling stuff
1889 2013-02-24 20:49:18 <BlueMatt> https://github.com/TheBlueMatt/test-scripts/blob/master/build-script.sh
1890 2013-02-24 20:49:23 <BlueMatt> check there for how to build
1891 2013-02-24 20:49:30 <BlueMatt> oh, qmake bitcoin-qt.pro BITCOIN_QT_TEST=1 USE_UPNP=-
1892 2013-02-24 20:49:39 <BlueMatt> I believe you may have to make clean first iirc
1893 2013-02-24 20:50:16 <sipa> ok, thanks
1894 2013-02-24 20:50:28 WolfAlex_ has quit (Ping timeout: 260 seconds)
1895 2013-02-24 20:50:34 <sipa> i was wondering whether to add -DVERIFY_OPTIMIZED_SECP256K1 for it
1896 2013-02-24 20:50:49 <sipa> guess it can't hurt
1897 2013-02-24 20:50:50 <forloop> sipa: I terminated bitcoin-qt, and the process hung around for over 8 minutes.  I downloaded 0.8 and started.  it is in the process of reloading the entire block chain.  see you in two days.
1898 2013-02-24 20:50:58 <BlueMatt> sipa: i doubt it does any sigchecks
1899 2013-02-24 20:51:04 <sipa> forloop: it should only take 1-2 hours
1900 2013-02-24 20:51:16 <sipa> forloop: 0.8 is somewhat faster than 0.7 :)
1901 2013-02-24 20:52:05 <forloop> sipa:  sorry, it says it is "reindexing blocks on disk"
1902 2013-02-24 20:52:33 <sipa> i know
1903 2013-02-24 20:54:54 <sipa> heh, i just realized we suddently use 70001 as protocol version
1904 2013-02-24 20:55:12 <sipa> where does that number come from?
1905 2013-02-24 20:55:26 <BlueMatt> bloom filters set that
1906 2013-02-24 20:55:31 <BlueMatt> do not remember why that was set
1907 2013-02-24 20:55:34 <sipa> hmm, i should have noticed
1908 2013-02-24 20:55:41 <BlueMatt> I think it was written for 0.7, so that was used
1909 2013-02-24 20:55:47 <sipa> i though the idea was to use 60000+N from now on for protocol numbers
1910 2013-02-24 20:55:52 <BlueMatt> oh, was it
1911 2013-02-24 20:55:54 <BlueMatt> sorry my fault then
1912 2013-02-24 20:56:00 <sipa> well, too late now :)
1913 2013-02-24 20:56:10 <BlueMatt> anyway, no big deal I suppose
1914 2013-02-24 20:56:26 <sipa> let's change it to 31827487 in the next update
1915 2013-02-24 20:56:27 <BlueMatt> we still have a while before we hit INT_MAX....
1916 2013-02-24 20:56:46 <sipa> so people can't complain it is connected to the reference client version
1917 2013-02-24 20:56:55 <BlueMatt> I prefer 3141569
1918 2013-02-24 20:57:21 <sipa> why not 3141592
1919 2013-02-24 20:57:34 da2ce7 has joined
1920 2013-02-24 20:57:39 <BlueMatt> because I dont know pi very well apparently?
1921 2013-02-24 20:57:44 <sipa> ahaa!
1922 2013-02-24 20:57:49 FredEE has joined
1923 2013-02-24 20:57:56 <sipa> wrong answer
1924 2013-02-24 20:58:07 <sipa> you just just have claimed it was Corallo's constant
1925 2013-02-24 20:58:21 <Luke-Jr> I prefer 314159265358979
1926 2013-02-24 20:58:30 <Luke-Jr> but our protocol versions aren't wide enough :<
1927 2013-02-24 20:58:33 <BlueMatt> sipa: lol, ok Ill do that next time
1928 2013-02-24 20:58:50 <sipa> Luke-Jr: so you just do that modulo 2^32 :)
1929 2013-02-24 20:58:53 <HM> I prefer to use base pi encoding and just use 1
1930 2013-02-24 20:58:57 da2ce7_d has quit (Ping timeout: 276 seconds)
1931 2013-02-24 20:59:01 <sipa> HM: you mean 10
1932 2013-02-24 20:59:02 <Luke-Jr> hm, maybe.
1933 2013-02-24 20:59:08 <HM> erm
1934 2013-02-24 20:59:17 <HM> the key didn't work? :}
1935 2013-02-24 20:59:28 <Luke-Jr> hm?
1936 2013-02-24 21:00:19 <TD> hey there
1937 2013-02-24 21:00:24 <BlueMatt> hi TD
1938 2013-02-24 21:00:38 <bitnumus> bitcoin-qt using 330% CPU ??
1939 2013-02-24 21:00:46 <Luke-Jr> bitnumus: sounds about right
1940 2013-02-24 21:00:55 <BlueMatt> bitnumus: yep, it does multi-threaded signature verification now
1941 2013-02-24 21:00:55 <bitnumus> o rly?
1942 2013-02-24 21:01:09 <BlueMatt> do we have an option to disable that, or force the number of threads, btw?
1943 2013-02-24 21:01:12 <bitnumus> 330%, im being dumb i know but i dont see how that is even possible
1944 2013-02-24 21:01:22 <Luke-Jr> BlueMatt: see release notes for option
1945 2013-02-24 21:01:27 <bitnumus> top measures across all cores so its 330% / 4 then ?
1946 2013-02-24 21:01:30 <BlueMatt> Luke-Jr: ok, just wanted to make sure
1947 2013-02-24 21:01:34 <BlueMatt> bitnumus: yep
1948 2013-02-24 21:01:48 <K1773R> bitnumus, 330% is correct
1949 2013-02-24 21:01:54 <K1773R> means 3 full cores and 30% of another core
1950 2013-02-24 21:02:10 <K1773R> nothing dumb about it
1951 2013-02-24 21:02:17 <BlueMatt> or, more likely, average 82.5% of each core
1952 2013-02-24 21:02:41 <bitnumus> the later blocks take so long.
1953 2013-02-24 21:02:48 <Luke-Jr> BlueMatt: I think K1773R's might be more likely, given the workload
1954 2013-02-24 21:03:09 <BlueMatt> Luke-Jr: well, ok, probably 1 core + 230/3 of the other 3
1955 2013-02-24 21:03:54 <Luke-Jr> I'd assume it's 70% short due to not having enough signatures to verify at times - so 1 core gets left idle
1956 2013-02-24 21:04:05 DamascusVG has joined
1957 2013-02-24 21:04:05 DamascusVG has quit (Changing host)
1958 2013-02-24 21:04:05 DamascusVG has joined
1959 2013-02-24 21:04:17 <BlueMatt> Luke-Jr: well if you're short, it should be random which core ends up being left idle, not constant
1960 2013-02-24 21:04:47 <Luke-Jr> hmm, perhaps
1961 2013-02-24 21:05:39 <sipa> Luke-Jr: it more due to naive scheduling
1962 2013-02-24 21:05:46 <sipa> and locking overhead
1963 2013-02-24 21:06:20 <sipa> (it wakes the sigcheck threads when a new block is being verified, and then blocks until all sigthread threads are done)
1964 2013-02-24 21:06:32 <sipa> so you have some startup/shutdown cycle of the threads every block
1965 2013-02-24 21:08:57 mappum has joined
1966 2013-02-24 21:13:14 cheako has joined
1967 2013-02-24 21:13:52 Haifisch has joined
1968 2013-02-24 21:14:13 rbecker is now known as RBecker
1969 2013-02-24 21:17:17 grau_ has joined
1970 2013-02-24 21:17:27 grau has quit (Read error: Operation timed out)
1971 2013-02-24 21:19:30 da2ce7_d has joined
1972 2013-02-24 21:21:11 da2ce7 has quit (Ping timeout: 256 seconds)
1973 2013-02-24 21:24:57 m00p has joined
1974 2013-02-24 21:26:32 saivann has joined
1975 2013-02-24 21:26:47 <TD> hey saivann
1976 2013-02-24 21:26:51 i2pRelay has quit (Remote host closed the connection)
1977 2013-02-24 21:26:51 <TD> i am proofreading and typo-fixing the site now
1978 2013-02-24 21:27:25 <saivann> TD : awesome! I was doing the initial french translation by the time
1979 2013-02-24 21:28:02 <saivann> TD How is it going, do you find more than cosmetic mistakes?
1980 2013-02-24 21:28:30 <TD> mostly it's just minor typos, spelling errors, etc. in a few places i've rewritten a sentence or two because it didn't flow well
1981 2013-02-24 21:28:40 <TD> i've done about a quarter of the pages, i think
1982 2013-02-24 21:29:26 <saivann> TD In the vocabulary / hash-rate section, there is an important mistake. billion must be replaced by trillion
1983 2013-02-24 21:30:01 <TD> ok
1984 2013-02-24 21:30:04 <TD> i'll do that now
1985 2013-02-24 21:31:06 <sipa> hmm, which number is it about?
1986 2013-02-24 21:31:38 <saivann> TD Great. If you see any suggestion, don't hesitate. I tried to make the best texts possible and any improvement is welcome.
1987 2013-02-24 21:31:59 m00p has quit (Ping timeout: 255 seconds)
1988 2013-02-24 21:32:02 i2pRelay has joined
1989 2013-02-24 21:32:36 <TD> it's really good
1990 2013-02-24 21:32:46 <TD> just needs some polishing and then the inevitable mass debates and tweaks :)
1991 2013-02-24 21:32:59 <saivann> TD Love that :)
1992 2013-02-24 21:33:12 <TD> sipa: there is a new website for bitcoin.org being developed by saivann
1993 2013-02-24 21:33:15 <TD> see the foundation forum
1994 2013-02-24 21:34:22 JZavala has joined
1995 2013-02-24 21:34:50 <sipa> "Bitcoin payments are irreversibles" -s
1996 2013-02-24 21:35:05 <TD> saivann: the "how bitcoin works" page needs a bit more rephrasing than most of the others
1997 2013-02-24 21:35:10 <TD> sipa: that's the kind of mistake i'm fixing
1998 2013-02-24 21:35:14 <TD> will be submitting a pull req son
1999 2013-02-24 21:37:25 monkeynipple_ has joined
2000 2013-02-24 21:37:38 <sipa> why "Bitcointalk official forum" ?
2001 2013-02-24 21:38:06 <saivann> TD This page was actually one of the hardest to write. A summary of how Bitcoin works is a very hard task.
2002 2013-02-24 21:38:09 da2ce7 has joined
2003 2013-02-24 21:38:10 <saivann> sipa it is not official?
2004 2013-02-24 21:38:30 <TD> yeah
2005 2013-02-24 21:38:41 <TD> saivann: argh. old arguments. it's technically not official even though it's the most popular forum by far
2006 2013-02-24 21:38:45 da2ce7_d has quit (Ping timeout: 256 seconds)
2007 2013-02-24 21:38:49 <TD> saivann: due to the history of it having very loose moderation
2008 2013-02-24 21:39:04 <sipa> indeed
2009 2013-02-24 21:39:10 <saivann> TD Then we should remove the official word
2010 2013-02-24 21:40:02 <saivann> You are more likely to know these things better than I, you are there since many years. Which is not my case
2011 2013-02-24 21:40:24 monkeynipples has quit (Ping timeout: 252 seconds)
2012 2013-02-24 21:40:27 <saivann> Which is why your revision is above all necessary
2013 2013-02-24 21:40:44 <TD> yeah
2014 2013-02-24 21:41:32 <TD> hmm. i'm not sure about the explanation of mining. but for now i'll mostly leave it alone and we can work on a better one in a separate pullreq
2015 2013-02-24 21:44:06 <saivann> TD No problem. The goal I had was to describe the mining process in a language anybody would understand. So, with no technical words. Just focussing on what it does, in the most simple terms.
2016 2013-02-24 21:45:43 m00p has joined
2017 2013-02-24 21:46:20 RazielZ has joined
2018 2013-02-24 21:46:36 <TD> yeah
2019 2013-02-24 21:46:39 <saivann> TD I found that we often focus on double-spending when we speak of mining because it is the only issue that no other systems could fix. However, mining actually is not limited to prevention against double-spending. So the idea was to explain it as a whole.
2020 2013-02-24 21:46:40 <TD> it's a very difficult thing to do :)
2021 2013-02-24 21:47:12 <TD> i think it's probably worth mentioning that people mine using special hardware, that it's a competitive business and most people will never engage in mining
2022 2013-02-24 21:47:12 <saivann> We'll see if we get something that everyone believe to be accurate and understandable :)
2023 2013-02-24 21:47:49 <saivann> TD Yes, if any notion of "profit" comes somewhere, it should be made clear
2024 2013-02-24 21:49:03 Scrat has joined
2025 2013-02-24 21:49:47 <rabbit_> when i signrawmessage I get  { hex: "...", complete: false } -- does this mean the signing failed?
2026 2013-02-24 21:50:11 <sipa> rabbit_: it means that at least one input couldn't be signed
2027 2013-02-24 21:50:56 <gmaxwell> saivann: my expirence is the opposite. When most people show up to talk about mining they have _no_ concept of it except subsidy distribution, and it takes signficant effort to get them to realize that its also a consensus mechenism. Perhaps that explains some of your impression: we focus on double spending because most people miss it.
2028 2013-02-24 21:51:36 <rabbit_> sipa: hmm... does that imply a problem with the input? or with me trying to sign it?
2029 2013-02-24 21:52:15 <TD> saivann: btw could we keep the bitcoin.pdf in the root directory? moving it under files/ will break links
2030 2013-02-24 21:52:29 <gmaxwell> 12:26 < BlueMatt> gmaxwell: actually, thinking about it a bit more, Id go for a relatively high-base logarithm on value using the original formula
2031 2013-02-24 21:52:50 monkeynipple_ is now known as monknipples
2032 2013-02-24 21:52:51 <gmaxwell> still non-linear, and it then doesn't include the uxto factor which was _the_ reason for discussing it at all.
2033 2013-02-24 21:52:57 monknipples is now known as monkeynipples
2034 2013-02-24 21:53:14 <saivann> gmaxwell : I have no doubt about that. Actually, I want the site to explain mining as a whole, including the consensus and double-spend aspects. But not only double-spending. And I also want to keep away from the notion of profit, or make it very clear like what TD said, so that people really knows what it is
2035 2013-02-24 21:53:24 Z0rZ0rZ0r has quit (Quit: Wheeeee)
2036 2013-02-24 21:53:48 <BlueMatt> gmaxwell: original formula as in the one from months ago
2037 2013-02-24 21:53:57 <saivann> TD : Just to make the root more clean, we could do a 301 redirect in the .htaccess?
2038 2013-02-24 21:54:01 <gmaxwell> saivann: What do you mean "as a whole"?
2039 2013-02-24 21:54:45 <sipa> well mining is the combination of two systems in bitcoin: probabilistic consensus, and introduction of currency
2040 2013-02-24 21:54:52 <gmaxwell> saivann: now I'm wondering what you think mining is for except ordering the history and distributing the initial coins. :)
2041 2013-02-24 21:54:55 CaptainBlaze has quit (Quit: CaptainBlaze)
2042 2013-02-24 21:55:21 <sipa> the reason mining exists is purely the consensus part, but that doesn't mean that is all there is to the result
2043 2013-02-24 21:55:40 CaptainBlaze has joined
2044 2013-02-24 21:55:53 <saivann> gmaxwell Double spending is only one of the attributes of mining. I was refering to the fact that most online (often unofficial) documentation about Bitcoin focuses on double-spending when speaking of Bitcoin mining, for historical reasons. And as such, what I mean by "as a whole" is that we should try to explain the real nature of the consensus system, and at the same time make it clear on it prevents double-spending.
2045 2013-02-24 21:56:29 JZavala has quit (Ping timeout: 252 seconds)
2046 2013-02-24 21:56:33 <saivann> *how* it prevents
2047 2013-02-24 21:56:50 <amiller> saivann, i think you're right and that's a really good idea
2048 2013-02-24 21:57:10 <sipa> i'm not sure it's viable to try to explain that without using technical jargon in an understandable way in one paragraph :)
2049 2013-02-24 21:57:14 <amiller> saivann, everyone i run into who knows only a little bit about bitcoin seems to completely misunderstand how mining works and it's almost entirely because 'mining' is a poor word
2050 2013-02-24 21:57:25 <BlueMatt> gmaxwell: wait...the algorithm you sent as the one from months ago doesnt make sense... sum(value*age)/α*max(size,2*size+utxo_change)) means bigger is better or sum(value*age)/(α*max(size,2*size+utxo_change))
2051 2013-02-24 21:57:27 <amiller> i think a short but better explanation could go along way
2052 2013-02-24 21:57:29 <gmaxwell> saivann: I'm not sure what "most online (often unofficial) documentation" focuses on double spending. I am quite confident that you're entirely wrong on that— something like 99.9% of all online discussion makes no mention of double spending at all.  Not that it matters, I'm just kind of puzzled.
2053 2013-02-24 21:58:12 <amiller> every other press release or crap article on the internet says that bitcoin prevents double spending because the miners create the money by solving hard math problems and that's just misleading
2054 2013-02-24 21:58:13 <gmaxwell> BlueMatt: group it how I meant it, of course.
2055 2013-02-24 21:58:24 <BlueMatt> gmaxwell: ok, just wanted to make sure
2056 2013-02-24 21:58:25 <saivann> amiller sipa : Well I wanted to give it a try, because I think that we have a chance to explain it more simply for non-technical people
2057 2013-02-24 21:58:30 <TD> saivann: btw i already have a copy of the FAQ converted to html: https://github.com/mikehearn/bitcoin.org/commit/30d42fd12dbeeaa501d2007d63c9df479875a2ce
2058 2013-02-24 21:58:51 da2ce7_d has joined
2059 2013-02-24 21:59:09 da2ce7 has quit (Ping timeout: 264 seconds)
2060 2013-02-24 21:59:26 <saivann> TD Great..!! I will enjoy having this part in the website
2061 2013-02-24 21:59:31 <gmaxwell> amiller: dunno, for a long time even the wikipedia article made no mention of consensus or double spending. (since been fixed)
2062 2013-02-24 21:59:49 <gmaxwell> (I admit, this was mostly due to editing by Atlas, still—)
2063 2013-02-24 22:00:15 <amiller> i also want to protest the wiki article about cross contract spending, since it confused HM a bit
2064 2013-02-24 22:00:23 <gmaxwell> amiller: fix it.
2065 2013-02-24 22:00:35 <sipa> protest or protect?
2066 2013-02-24 22:00:47 <gmaxwell> saivann: where is the text you're working on?
2067 2013-02-24 22:00:58 <saivann> gmaxwell I might be wrong, this is my perception of a Bitcoin user "outside the community". Since I'm now there.. I might lose this perception and become a full bitcoin "insider"
2068 2013-02-24 22:00:58 <amiller> could i put one sentence that says this scheme isn't secure yet because it either has a race condition where one person walks away with the money or else it allows someone to lock up your funds forever?
2069 2013-02-24 22:01:26 <gmaxwell> saivann: well I think its tremendously good if you're finding things that even bother mentioning mining as a consensus mechenism.
2070 2013-02-24 22:02:03 <amiller> or "cross chain transactions are generally insecure because the timelines of different chains are not necessarily synchronized"
2071 2013-02-24 22:02:14 <saivann> gmaxwell its published in the fondation forum, git and http demo server : http://174.142.20.146/en/
2072 2013-02-24 22:03:51 <sipa> saivann: well i think you're doing good regarding correctness - i won't judge whether it's understandable
2073 2013-02-24 22:04:27 <gmaxwell> saivann: I consider it an absole non-starter to promote webwallet services on bitcoin.org.
2074 2013-02-24 22:04:53 discrete has joined
2075 2013-02-24 22:05:02 <sipa> i do dislike the fact that transactions are said to have a from address, and that address balances exists; but i guess those are inevitable if you want to simplify
2076 2013-02-24 22:05:12 <saivann> gmaxwell absole?
2077 2013-02-24 22:05:18 <sipa> absolute, i guess
2078 2013-02-24 22:05:26 <gmaxwell> Indeed.
2079 2013-02-24 22:06:06 <gmaxwell> ugh.
2080 2013-02-24 22:06:08 <saivann> gmaxwell You mean you are against webwallet on bitcoin.org? (Please consider to be indulgent, I'm not an english native speaker)
2081 2013-02-24 22:06:46 <gmaxwell> saivann: Bitcoin.org must not promote any centralized web-wallet services.
2082 2013-02-24 22:06:48 <TD> saivann: i'm going to rewrite the section on payment fraud
2083 2013-02-24 22:06:56 <saivann> sipa this is all there to be improved and discussed. If you suggest something better, I will welcome the suggestion.
2084 2013-02-24 22:07:05 <TD> gmaxwell: that's something you can thrash out with gavinandresen as he is quite keen on blockchain.info
2085 2013-02-24 22:07:07 <BlueMatt> gmaxwell: sum(utxo_bytes*log_highbase(value)*age/α)/utxo_bytes_created where α is chosen as to not overweight utxo_bytes_destroyed over utxo_bytes_created note that I deliberately leave out size as miners will sort the non-free section by priority/size and then the free section will be sorted only based on priority
2086 2013-02-24 22:07:21 <gmaxwell> TD: Yes, I've thrashed it out with gavin previously and he backed off from it.
2087 2013-02-24 22:08:17 JDuke128 has quit (Quit: Computer has gone to sleep.)
2088 2013-02-24 22:08:20 JZavala has joined
2089 2013-02-24 22:08:40 <BlueMatt> gmaxwell: ehh, oops sorry, not log there, exponent
2090 2013-02-24 22:09:27 <sipa> i have less problems with centralized clients as such, than with clients that in practice will not have any verification
2091 2013-02-24 22:09:35 <BlueMatt> gmaxwell: no, sorry yes log, but add one
2092 2013-02-24 22:09:48 <BlueMatt> gmaxwell: so that spending 1-satoshi inputs does actually give you something based on utxo_bytes
2093 2013-02-24 22:09:51 <gmaxwell> In particular, no one has any answers about b.i's level of insurance or having-been audited.  In the time since that last discussion some of these concerns were validated when b.i was caught violating their own data retention claims after Roger used their database to disclose the identity of one of their mywallet users.
2094 2013-02-24 22:10:29 <gmaxwell> sipa: Obviously thats a concern too— but even validation is moot when the client is just JS loaded on a webpag.e
2095 2013-02-24 22:10:34 <saivann> gmaxwell That is indeed a good discussion. We actually promote softwares that use remote blockchains for performances issues. Webwallets only goes a step further and stores users funds online. I think we need to mention that because a lot of people will only want online wallets. Though, I am divided about the idea of making promotion to ANY service or software
2096 2013-02-24 22:11:22 <gmaxwell> saivann: if nothing is recommended then it will just end up being a contest of who pays the most for advertising. There is no 'no choice' option.
2097 2013-02-24 22:11:35 <sipa> when you go to the point of providing any client (centralized or not) publicity on that page, the question about who will decide what gets advertized
2098 2013-02-24 22:11:48 <sipa> becomes inevitable
2099 2013-02-24 22:12:04 <gmaxwell> I don't have any concern having that discussion— we've had it before of course.
2100 2013-02-24 22:12:28 <sipa> a rule like "no centralized service" is easy in that regard
2101 2013-02-24 22:12:29 <saivann> Exactly.. The page has been done in a way that allows to add a lot of them.. I thought that _if_ we choose to promote wallets, we should not do it for years.
2102 2013-02-24 22:12:45 <sipa> but what about an android SPV app that gets autoupdated in practice by everyone?
2103 2013-02-24 22:12:56 <BlueMatt> gmaxwell: actually, ignore my rambling that still doesnt make sense, give me a few hours
2104 2013-02-24 22:13:05 <sipa> that has as many risks as a centralized site that suddenly changes the code to send private keys to the server
2105 2013-02-24 22:13:25 <sipa> is there a difference in centralization, in practice?
2106 2013-02-24 22:13:47 <muhoo> that's malware
2107 2013-02-24 22:13:52 <Goonie> sipa: the difference is, people can audit the source and build from that
2108 2013-02-24 22:14:05 <sipa> Goonie: they can, but they can also inspect the site's source
2109 2013-02-24 22:14:16 <sipa> and in practice, ~almost nobody will do either
2110 2013-02-24 22:14:22 <gmaxwell> sipa: There is another factor which is harder to discuss— which is commonality of fault. To the extent that there exist effectively centeralized options it is much better for our economy if no one option has a very large share of users.
2111 2013-02-24 22:14:32 <Goonie> is b.i open source? did not know that
2112 2013-02-24 22:14:43 <muhoo> hmm, thinking about it, i could see a "wallet sync" feature being added to i.e. android spv clients, which would essentially be a web wallet
2113 2013-02-24 22:14:57 <sipa> Goonie: i'm talking about the kind of service where keys are kept in the browser, not about e-wallets
2114 2013-02-24 22:15:15 <muhoo> sync is all over google-land. as soon as you fire up an anroid, it tries to send all your private data to "the cloud". one could easily imagine a wallet app which'd do the same
2115 2013-02-24 22:15:18 <gmaxwell> muhoo: when I say webwallet I'm mostly speaking of things where the server controls the code.
2116 2013-02-24 22:16:55 <muhoo> this reminds me of the age-old debates about security vs. convenience. as soon as a system goes mainstream, the pressure to trade security for convenience goes parabolic. this is why, for example, nobody's email is encrypted.
2117 2013-02-24 22:16:56 <Goonie> if people don't audit the code although they could its their decision, not ours.
2118 2013-02-24 22:17:19 <sipa> Goonie: i disagree
2119 2013-02-24 22:17:46 <amiller> i bumped sergio's old forum thread where he describes a different algorithm than the one on the wiki, and in particular provides precisely the same argument that i do about how the wiki article protocol is faulty
2120 2013-02-24 22:17:51 <muhoo> hehe, grandma is going to audit code?
2121 2013-02-24 22:18:06 <sipa> no, but the cost of auditing matters
2122 2013-02-24 22:18:12 <sipa> or the convenience, rather
2123 2013-02-24 22:19:02 <Goonie> sure, the outcome of an audit can also be "this code is un-auditable, because its too messy or just too much"
2124 2013-02-24 22:19:32 <TD> gmaxwell: the Roger thing was because the user in question had told the site to monitor his addresses and email him when there was activity there
2125 2013-02-24 22:19:35 <sipa> for a website (assume the type that normally only keeps private keys in the browser), you'd have to verify it every time you visit if you want to not trust it more than a site that just keeps you funds
2126 2013-02-24 22:19:39 <TD> gmaxwell: so it's not fundamental to the approach
2127 2013-02-24 22:20:01 <Scrat> I think there are 2 types of wallets: the ones that store your private keys in plaintext and as such can do a wallet-to-wallet transaction off the chain and those who do not
2128 2013-02-24 22:20:09 <Scrat> webwallets that is
2129 2013-02-24 22:20:11 <TD> with regards to Android auto-update, yes, it's an issue though updates aren't silent. at some point we should try splitting the android signing key using threshold RSA so it takes more than one person to trigger an update
2130 2013-02-24 22:20:52 <sipa> Goonie: at least with an android update, chances exist that i'll hear about someone complaining about weird code in a new version
2131 2013-02-24 22:21:08 <sipa> with the website, they could just serve me personally a different version
2132 2013-02-24 22:21:45 <sipa> and no 'herd immunity' will help (=me trusting that i'd hear about problems by others doing auditing)
2133 2013-02-24 22:22:44 balrog has joined
2134 2013-02-24 22:22:57 <sipa> on the other hand, is there any way for me to verify that the android wallet i'm running is compiled from the published source?
2135 2013-02-24 22:22:58 <Goonie> sipa: Interestingly, something like this is possible with Android as well, because you can serve different APKs to different OS version etc.
2136 2013-02-24 22:22:59 grau_ has quit (Remote host closed the connection)
2137 2013-02-24 22:23:20 Haifisch has quit (Ping timeout: 260 seconds)
2138 2013-02-24 22:23:22 <sipa> Goonie: true, slightly harder, but indeed
2139 2013-02-24 22:23:30 <Goonie> so for example, I could put up an APK just for Android 2.1 (which I deprecated some months ago) that signs the remaining coins over to me
2140 2013-02-24 22:23:35 <TD> phew
2141 2013-02-24 22:23:47 <Goonie> probably nobody would notice (-:
2142 2013-02-24 22:24:04 <TD> sipa: well, it's just java, so in theory making a reproducible build should be quite easy
2143 2013-02-24 22:24:08 <TD> we haven't tried it yet though
2144 2013-02-24 22:24:20 <sipa> ;;bc,blocks
2145 2013-02-24 22:24:21 <gribble> 222925
2146 2013-02-24 22:24:36 <TD> the whole community needs to lock down the ecosystem at some point against compromise of individuals. but it's a lot of work. right now we need to fix performance and reliability first.
2147 2013-02-24 22:25:09 <gmaxwell> TD: this happened about two weeks after a nice conversation I had on the forum with PIUK where he insisted that they log nothing identifying about mywallet users. And I countered that while I'm glad to hear that, he can't disprove that he hasn't started logging.  Worse, their response to the whole drama was to hash the matching addresses and claim that this makes the data irretrievable— a misleading claim at best.
2148 2013-02-24 22:25:40 <TD> he probably meant they log nothing identifiable unless users specifically want to be tracked/identified
2149 2013-02-24 22:25:43 <TD> but sure
2150 2013-02-24 22:25:57 <TD> you can't really know what the service does. heck, it logs the IP address of every broadcast transaction it can find
2151 2013-02-24 22:26:01 <TD> that says a lot by itself, i think
2152 2013-02-24 22:26:05 <gmaxwell> Why bother working on performance when everyone is being directed to some webwallet which has none of the performance challenges of non-centeralized systems? ::shrugs::
2153 2013-02-24 22:26:41 <gmaxwell> TD: not every— they don't display addresses for their own users.  And complaining to them via email gets you a recommendation to use their laundering service.
2154 2013-02-24 22:27:08 <sipa> gmaxwell: ehmm, he *could* disprove that he hasn't started logging: by showing you a log :p
2155 2013-02-24 22:27:09 <TD> hah
2156 2013-02-24 22:27:12 da2ce7 has joined
2157 2013-02-24 22:27:25 <TD> gmaxwell: the reason people are being recommended to use web wallets and things like BitcoinSpinner is *because* of performance
2158 2013-02-24 22:27:33 <TD> gmaxwell: or at least that's one very big reason
2159 2013-02-24 22:27:35 da2ce7_d has quit (Ping timeout: 244 seconds)
2160 2013-02-24 22:27:44 <TD> BitPay *still* recommend and demo Spinner to people over Goonies app
2161 2013-02-24 22:27:47 <muhoo> the more accepted btc is, the more centralized it will be. these web services that act like fiat banks are inevitable. at some point. visa and such will start putting up webwallets.
2162 2013-02-24 22:27:57 <gmaxwell> sipa: heh. read what I meant. I actually did point out that the one way was provable but not the other, they they went on to prove it. :P
2163 2013-02-24 22:27:59 <TD> once we've got performance matched with Spinner I'm planning to ask Tony/Stephen to stop doing htat
2164 2013-02-24 22:28:48 <sipa> gmaxwell: sure, just being pedantic :)
2165 2013-02-24 22:29:14 <gmaxwell> TD: b.i being the only really working block explorer really captures it a lot of users. ... but sure, what can I do to help improve performance? is multibit a reasonable testhardness for screwing around with bitcoinj on a desktop?
2166 2013-02-24 22:29:14 <MC1984> spinner seemed ok, just very "beta"
2167 2013-02-24 22:29:24 <muhoo> TD: convenience, i'd argue, not performance
2168 2013-02-24 22:30:28 <TD> afk back in a bit
2169 2013-02-24 22:31:12 i2pRelay has quit (Remote host closed the connection)
2170 2013-02-24 22:31:49 i2pRelay has joined
2171 2013-02-24 22:32:35 <muhoo> and familiarity. i'm not sure it's possible for a decentralized system to win a convenicence/famliarity war against a centralized system. it's fighting human nature. interesting problem, but not an easy one.
2172 2013-02-24 22:33:29 <muhoo> speaking as someone who used to run his own sendmail server in the 90s, but now just uses gmail :-/
2173 2013-02-24 22:33:33 <MC1984> can security ever be convenient?
2174 2013-02-24 22:34:09 <MC1984> real trustless security
2175 2013-02-24 22:34:26 <MC1984> i was looking at the silent circle stuff the other day
2176 2013-02-24 22:34:32 <muhoo> MC1984: maybe a bit philosiphical for #bitcoin-dev, but yes, that's really what i was trying to say.
2177 2013-02-24 22:34:37 <MC1984> you have to pay for it but they claim they cant access your stuff
2178 2013-02-24 22:36:08 RBecker is now known as rbecker
2179 2013-02-24 22:36:09 <muhoo> just as a caution, really, not intending to get into handwaving debates, but to point out that's the scope of the problem.
2180 2013-02-24 22:36:26 <MC1984> mega is also trying to make that sort of security vey easy, for his own sake more than his customers
2181 2013-02-24 22:37:12 X-Scale has joined
2182 2013-02-24 22:38:39 <Tykling> is there a forced upgrade or something ?
2183 2013-02-24 22:38:51 <sipa> for?
2184 2013-02-24 22:39:18 <Tykling> I have a node that still runs 0.7 that I was planning on upgrading to 0.8
2185 2013-02-24 22:39:22 <Tykling> error: {"code":-2,"message":"Safe mode: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."}
2186 2013-02-24 22:39:44 <sipa> Tykling: typically means your database got corrupted
2187 2013-02-24 22:40:08 <Tykling> I see, I thought there might be something that required upgrading to 0.8
2188 2013-02-24 22:40:21 <sipa> no, certainly not
2189 2013-02-24 22:40:32 <Tykling> okay, I thought it was a bit weird
2190 2013-02-24 22:42:20 da2ce7_d has joined
2191 2013-02-24 22:44:12 da2ce7 has quit (Ping timeout: 252 seconds)
2192 2013-02-24 22:44:45 <Tykling> ok so
2193 2013-02-24 22:44:53 <Tykling> corrupted blockchain or ?
2194 2013-02-24 22:45:00 <sipa> most likely
2195 2013-02-24 22:45:21 <sipa> but 0.8 uses a new database format anyway, so it will rebuild it on first start
2196 2013-02-24 22:45:40 <Tykling> so if I kill it and upgrade it should sort it while it converts to the new format
2197 2013-02-24 22:45:47 <rabbit_> i've created a rawtransaction, but when i go to sign it, i'm told the "vout" key is not present (http://pastie.org/private/jquwoqey9692g0yobgvaa)
2198 2013-02-24 22:46:00 <rabbit_> the same command works if the vout value is 0
2199 2013-02-24 22:46:15 <rabbit_> am I misunderstanding the role of vout?
2200 2013-02-24 22:46:18 <sipa> rabbit_: vout is an index
2201 2013-02-24 22:46:22 <rabbit_> lol
2202 2013-02-24 22:46:23 <sipa> it's an integer
2203 2013-02-24 22:46:40 <sipa> if it is 4, it means you're spending output number 4 of the specified txid
2204 2013-02-24 22:47:04 <rabbit_> OH... in case a transaction has many... transactions?
2205 2013-02-24 22:47:15 <sipa> outputs
2206 2013-02-24 22:47:19 <Tykling> is there a "clean" way to shutdown bitcoind to avoid database corruption in the future ?
2207 2013-02-24 22:47:36 <sipa> Tykling: just kill it with sigterm or sigint
2208 2013-02-24 22:47:52 <rabbit_> a transaction would have more than one output if I were to append multiple { address:amount } objects yah?
2209 2013-02-24 22:47:59 <sipa> yes
2210 2013-02-24 22:48:00 <Tykling> I've been doing kill -9 so that explains it
2211 2013-02-24 22:48:02 <rabbit_> gotcha
2212 2013-02-24 22:48:02 <Tykling> :)
2213 2013-02-24 22:48:04 <Tykling> thanks
2214 2013-02-24 22:48:12 <sipa> rabbit_: really, read about how bitcoin transaction work before using the raw tx interface
2215 2013-02-24 22:48:18 <sipa> rabbit_: you WILL shoot yourself in the foot
2216 2013-02-24 22:48:31 <TD> muhoo: well, the two apps are of equal convenience. install from the store, run …. you're done
2217 2013-02-24 22:48:32 <rabbit_> sipa: i am, as I go through it..
2218 2013-02-24 22:48:38 <TD> muhoo: the primary differentiator is performance
2219 2013-02-24 22:49:12 <TD> gmaxwell: yeah multibit (whatever the most recent preview/rc is) is a good place to start. or just bitcoinj with the command line wallet-tool app
2220 2013-02-24 22:49:13 MobPhone has quit (Read error: Connection reset by peer)
2221 2013-02-24 22:49:14 <rabbit_> sipa: just landed here... https://en.bitcoin.it/wiki/Transactions#Input
2222 2013-02-24 22:49:42 <TD> gmaxwell: there's really only one major project left though, perf-wise, which is to start syncing getheaders for new clients from the latest checkpoint
2223 2013-02-24 22:49:56 <TD> and use a ring-buffer for holding block headers instead of just appending them to a file
2224 2013-02-24 22:50:00 <TD> i'm planning on fixing that next
2225 2013-02-24 22:50:11 <TD> then SPV client performance should be very comparable to Spinner/Electrum
2226 2013-02-24 22:51:04 <TD> gmaxwell: if you feel like breaking out your java ide, then a proper implementation of fees would be a great patch. somehow it keeps getting put off because people just pay the min fee on every transaction and don't complain about it (much, relative to performance)
2227 2013-02-24 22:51:43 okok has joined
2228 2013-02-24 22:51:54 <TD> saivann: https://github.com/bitcoin-org/bitcoin.org/pull/16
2229 2013-02-24 22:52:39 bitafterbit has quit (Remote host closed the connection)
2230 2013-02-24 22:52:59 <saivann> TD excellent
2231 2013-02-24 22:54:12 <saivann> TD What do we do for the bitcoin.pdf file, a 301 redirect or do we put it at the root?
2232 2013-02-24 22:54:21 <TD> maybe it's easier to just put it at the root? i don't really mind
2233 2013-02-24 22:54:50 <saivann> Ok I'll take care of it
2234 2013-02-24 22:57:35 ynik is now known as dinox
2235 2013-02-24 22:57:42 anonanon123 has joined
2236 2013-02-24 23:00:34 ThomasV has quit (Read error: Operation timed out)
2237 2013-02-24 23:00:39 <HM> if you couldn't use "s" for secret
2238 2013-02-24 23:00:42 <HM> what letter would you use
2239 2013-02-24 23:01:06 <TD> ?
2240 2013-02-24 23:01:08 <HM> hmm i'll go with h for hash
2241 2013-02-24 23:01:11 <HM> command line option
2242 2013-02-24 23:01:47 freakazoid has joined
2243 2013-02-24 23:02:44 <saivann> TD that looks awesome. I added you as an admin in the repository
2244 2013-02-24 23:03:43 anonanon123 has quit (Quit: Page closed)
2245 2013-02-24 23:03:52 <TD> thanks. i still have more changes i'd like to make and will submit follow up pull reqs for them
2246 2013-02-24 23:03:56 <TD> but later :)
2247 2013-02-24 23:07:00 ThomasV has joined
2248 2013-02-24 23:09:47 Hashdog has quit (Remote host closed the connection)
2249 2013-02-24 23:10:12 kirill42 has joined
2250 2013-02-24 23:11:44 CaptainBlaze has quit (Quit: CaptainBlaze)
2251 2013-02-24 23:12:34 da2ce7 has joined
2252 2013-02-24 23:13:02 rbecker is now known as RBecker
2253 2013-02-24 23:13:21 da2ce7_d has quit (Ping timeout: 256 seconds)
2254 2013-02-24 23:14:26 kirill42 has quit (Ping timeout: 245 seconds)
2255 2013-02-24 23:16:11 ThomasV has quit (Ping timeout: 246 seconds)
2256 2013-02-24 23:18:40 CodeShark has joined
2257 2013-02-24 23:20:26 spaz926 has joined
2258 2013-02-24 23:20:37 spaz926 has left ()
2259 2013-02-24 23:24:30 one_zero has joined
2260 2013-02-24 23:26:49 Nesetalis is now known as Nes-asleep
2261 2013-02-24 23:27:59 <etotheipi_> petertodd: I finally know what you mean by "merkle sums" now, I think that's a fantastic idea
2262 2013-02-24 23:29:09 <etotheipi_> simple, efficient, useful... perhaps I just missed the paragraphs of discussion where they were mentioned/recommended
2263 2013-02-24 23:29:27 <sipa> what are merkle sums?
2264 2013-02-24 23:29:54 <amiller> they're further annotations of nodes in a tree that are made by summing up the annotations from the children
2265 2013-02-24 23:30:08 <amiller> in this case they're for having each node in the utxo tree store the sum of the balances of the subnodes
2266 2013-02-24 23:30:17 <sipa> oh, that idea
2267 2013-02-24 23:31:16 <etotheipi_> yeah, that never crossed my mind, and I don't remember anyone mentioning it before
2268 2013-02-24 23:35:55 freakazoid has quit (Ping timeout: 252 seconds)
2269 2013-02-24 23:37:11 DaQatz has quit (Ping timeout: 246 seconds)
2270 2013-02-24 23:37:33 Phoebus has quit (Ping timeout: 264 seconds)
2271 2013-02-24 23:41:21 da2ce7_d has joined
2272 2013-02-24 23:42:01 <gmaxwell> etotheipi_: I think I might have only given it a name a few days ago, when I added it to my alt-ideas page: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas (and realized that petertodd had already proposed the same idea without affixing a name to it)
2273 2013-02-24 23:42:16 <gmaxwell> (see the link from alt_ideas for peter todd's post)
2274 2013-02-24 23:43:39 da2ce7 has quit (Ping timeout: 260 seconds)
2275 2013-02-24 23:44:26 toffoo has joined
2276 2013-02-24 23:46:45 RBecker is now known as rbecker
2277 2013-02-24 23:48:13 m00p has quit (Read error: Operation timed out)
2278 2013-02-24 23:52:05 Phoebus has joined
2279 2013-02-24 23:53:01 TD has quit (Quit: TD)
2280 2013-02-24 23:55:19 da2ce7 has joined
2281 2013-02-24 23:55:54 da2ce7_d has quit (Ping timeout: 260 seconds)