1 2014-02-21 00:00:03 <justanotheruser> gmaxwell: Is the swap necessary?
  2 2014-02-21 00:00:27 <michagogo> cloud|justanotheruser: I think that's the script for the SHA256 collision bounty
  3 2014-02-21 00:00:34 <gmaxwell> justanotheruser: Yes.
  4 2014-02-21 00:00:44 <justanotheruser> michagogo|cloud: yeah, but could it be implemented without the swap
  5 2014-02-21 00:00:49 <michagogo> cloud|No
  6 2014-02-21 00:01:16 <michagogo> cloud|First, you use OP_2DUP OP_EQUAL OP_NOT OP_VERIFY to check that the inputs are different
  7 2014-02-21 00:01:50 <michagogo> cloud|The second phase, OP_SHA256 OP_SWAP OP_SHA256 OP_EQUAL, hashes one, swaps its hash with the other unhashed one, hashes the other one, and checks for equality
  8 2014-02-21 00:02:34 <michagogo> cloud|OP_SHA256 takes the top item on the stack, hashes it, and returns the hash to the stack
  9 2014-02-21 00:03:11 <michagogo> cloud|So you need to swap the hash of the first item with the second item, so the second item is on top, and gets hashed
 10 2014-02-21 00:03:43 <justanotheruser> Could you guys give me advice? I wanted to make a lisp-like language, but some opcodes don't really fit, like the stack ones. I can easily turn OP_ADD OP_MUL into (* (+ $1 $2) $3), but I don't know what to do with the stack ops. Is lisp impossible?
 11 2014-02-21 00:04:00 <sipa> what is your goal?
 12 2014-02-21 00:04:19 <justanotheruser> sipa: a language that is easier than just assembly to use
 13 2014-02-21 00:04:38 <sipa> you want to convert a lisp-like script language to the bitcoin script language?
 14 2014-02-21 00:04:45 <justanotheruser> sipa: yes
 15 2014-02-21 00:04:53 <sipa> so why do you care about stack operators?
 16 2014-02-21 00:04:59 <sipa> use them if you need to, don't if you don't
 17 2014-02-21 00:06:27 <emowataji> justanotheruser: are you creating a new scripting subsystem or are you compiling the lisp language down to the bitcoin one?
 18 2014-02-21 00:06:56 <justanotheruser> sipa: Hmm, so how would I implement the SHA256 bounty? (and (= (SHA256 $1) (SHA256 $2)) (not (= $1 $2)))
 19 2014-02-21 00:07:20 <justanotheruser> emowataji: just lisp syntax
 20 2014-02-21 00:07:27 <sipa> justanotheruser: looks good
 21 2014-02-21 00:08:02 <justanotheruser> sipa: THe biggest problem is the space it takes up. I don't want to use 50% more bytes than needed
 22 2014-02-21 00:08:22 <sipa> well then you'll need an optimizing compiler :)
 23 2014-02-21 00:08:54 <justanotheruser> sipa: yeah. The only thing unoptomized is the and, which could be a swap I think
 24 2014-02-21 00:09:10 <sipa> ??
 25 2014-02-21 00:09:27 <sipa> you're confused
 26 2014-02-21 00:09:34 <justanotheruser> I use OP_AND.. Let me see how many bytes my code is VS gmaxwells
 27 2014-02-21 00:09:34 <sipa> the and is in your source language
 28 2014-02-21 00:09:40 <sipa> ah
 29 2014-02-21 00:09:49 <sipa> you already have a compiler :)
 30 2014-02-21 00:09:57 <sipa> what do you compile it to?
 31 2014-02-21 00:10:07 <justanotheruser> sipa: I was thinking OP_AND when I said and
 32 2014-02-21 00:10:16 <justanotheruser> sipa: bitcoin scripting language?
 33 2014-02-21 00:10:27 <emowataji> your "(and (= (SHA256 $1) (SHA256 $2)) (not (= $1 $2)))" does the sha256 calculations always whereas I believe gmaxwells script doesn't
 34 2014-02-21 00:10:44 <sipa> emowataji: no operations semantics is given :)
 35 2014-02-21 00:10:49 <sipa> it may optimize it
 36 2014-02-21 00:10:54 <emowataji> ok
 37 2014-02-21 00:11:07 <sipa> justanotheruser: yes, what opcodes do you compile that fragment to?
 38 2014-02-21 00:11:21 <justanotheruser> sipa: one second
 39 2014-02-21 00:13:41 <justanotheruser> OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA256 OP_SWAP OP_SHA256 OP_EQUAL vs OP_2DUP OP_SHA256 OP_SHA256 OP_EQUAL OP_EQUAL OP_NOT OP_AND
 40 2014-02-21 00:14:03 <justanotheruser> 8 ops vs 7? did I miss something or did I make it smaller?
 41 2014-02-21 00:14:25 <emowataji> you need the swap
 42 2014-02-21 00:14:35 <emowataji> otherwise you are hashing the same thing twice
 43 2014-02-21 00:14:53 <justanotheruser> emowataji: ohhhh
 44 2014-02-21 00:16:10 <justanotheruser> What I was thinking was I would have to give the programmer a swap function, but really it will be behind the scenes
 45 2014-02-21 00:16:27 <sipa> no, you should decide automatically to use it
 46 2014-02-21 00:16:38 <sipa> swap doesn't fit in the sort of language you're building
 47 2014-02-21 00:16:46 <sipa> neither does DUP
 48 2014-02-21 00:16:51 <sipa> or VERIFY
 49 2014-02-21 00:17:15 <emowataji> justanotheruser: do some reasearch on compiling lisp to a stack machine bytecode
 50 2014-02-21 00:17:34 <justanotheruser> sipa: well DUP is part of it because you define the inputs $1, $2, etc
 51 2014-02-21 00:17:43 <sipa> yes, but it's there implicitly
 52 2014-02-21 00:17:48 <sipa> so should swap be
 53 2014-02-21 00:17:53 <sipa> or the other stack elements
 54 2014-02-21 00:17:54 <justanotheruser> sipa: yeah, you're right
 55 2014-02-21 00:18:03 <sipa> you need them to bring the right arguments to the front
 56 2014-02-21 00:18:45 <justanotheruser> Okay thanks. My goal is to make bitcoin scripts widely used
 57 2014-02-21 00:19:14 <justanotheruser> AFAIK right now all scripts must be hand made
 58 2014-02-21 00:19:53 <sipa> 
ACTION off

 59 2014-02-21 00:40:00 <wallet42> http://www.reddit.com/r/Bitcoin/comments/1yha91/mt_gox_needs_a_bailout/
 60 2014-02-21 01:21:33 <TheButterZone> https://github.com/vrotaru/btcticker/issues/4
 61 2014-02-21 01:53:38 <c--O-O> hi i have a weird question, can the devs help mtgox with php withdrawal coding, if he asked? i know that you know a lot. how can you do something like that?
 62 2014-02-21 01:54:37 <maaku> c--O-O: as far as I know mtgox has not offered to pay any developers to assist them
 63 2014-02-21 01:55:07 <maaku> and besides, their problems are their own. they are not in need of protocol developers to fix this
 64 2014-02-21 01:56:40 <c--O-O> maaku ok, well is there a way to offer a fix for free, something that both parties will be happy with, and is secure? I'm just saying maybe someone will freely help, given the conditions are right. because their prices have an effect on btc. just saying maybe there is a way to offer to fix the php code in a collaborative way.
 65 2014-02-21 01:57:02 <dhill> free help has been offered
 66 2014-02-21 01:57:09 <c--O-O> i see
 67 2014-02-21 01:57:21 <maaku> c--O-O: free help has been offered far beyond what would be reasonable
 68 2014-02-21 01:57:32 <c--O-O> i understand.
 69 2014-02-21 01:57:37 <maaku> given the antagonistic, anti-social stance they took
 70 2014-02-21 01:58:06 <maaku> but their problems are their own - it's their own wallet software and customer service procedures that lost them money
 71 2014-02-21 01:58:28 <maaku> if indeed they lost any money
 72 2014-02-21 01:58:32 <c--O-O> i know you would all give help now... yeah they aren't letting anyone help fix. I don't understand why, maybe they think someone will put some secret code in there to damage everything.
 73 2014-02-21 01:58:45 <justanotheruser> Sooo... weird question. If I made a tx with the script OP_PUSH 2 OP_ADD OP_PUSH 4 OP_EQUAL, how long would it take for someone to cash in?
 74 2014-02-21 01:58:46 <c--O-O> yes
 75 2014-02-21 01:59:26 <c--O-O> and does bitcoin have a standard exchange platform?
 76 2014-02-21 01:59:30 <c--O-O> i dunno.
 77 2014-02-21 01:59:38 <justanotheruser> c--O-O: bitcoin doesn't have a standard anything
 78 2014-02-21 01:59:46 <c--O-O> ok
 79 2014-02-21 01:59:48 <teward> exchanges are private entities
 80 2014-02-21 01:59:49 <justanotheruser> except for the protocol standard
 81 2014-02-21 02:00:03 <c--O-O> i thought all i could. it's them.
 82 2014-02-21 02:00:03 <justanotheruser> which is just what is allowed to be in a block
 83 2014-02-21 02:00:07 <teward> they can use whatever frameworks/software/interface/platform they want, so long as they follow the bitcoin protocol
 84 2014-02-21 02:00:18 <teward> as justanotheruser said
 85 2014-02-21 02:01:03 <justanotheruser> I think I'm going to try to figure out how long it takes bitcoin users to solve 2+X=4
 86 2014-02-21 02:01:57 <maaku> justanotheruser: not very long now that you mentioned it here ;)
 87 2014-02-21 02:03:02 <justanotheruser> I wonder if bounties for any millenium problems can be encoded into a script
 88 2014-02-21 02:06:37 <maaku> justanotheruser: almost certainly not
 89 2014-02-21 02:07:00 <maaku> script is extremely limited, especially now that most arithmetic and string manipulation opcodes are disabled
 90 2014-02-21 02:07:28 <maaku> that plus malleability makes script more of a novelty than something useful, most of the time
 91 2014-02-21 02:07:48 <justanotheruser> maaku: How does malleability effect it?
 92 2014-02-21 02:08:42 <maaku> justanotheruser: because most of the interesting application of scripts are to contracts, and malleability limits what you can do in terms of putting stuff together off-chain
 93 2014-02-21 02:09:16 <justanotheruser> maaku: I don't understand? Malleability can't change a script. What does it matter? TXID isn't part of a script?
 94 2014-02-21 02:09:30 <maaku> TXID is part of an input
 95 2014-02-21 02:10:01 <justanotheruser> maaku: yeah, but if it's in an input, it doesn't matter because the output being spent must already be in the blockchain
 96 2014-02-21 02:10:04 <maaku> so if you chain multiple transactions together (as often is done in contract protocols), you run the risk of the chain being broken by malleability
 97 2014-02-21 02:10:35 <maaku> justanotheruser: that's exactly the point. many of the interesting applications involve spending outputs which are *not* on the block chain
 98 2014-02-21 02:10:56 <maaku> e.g. pre-signed refund or escrow transactions, or somesuch
 99 2014-02-21 02:11:10 <justanotheruser> maaku: no way around that other than fixing malleability?
100 2014-02-21 02:14:40 <maaku> justanotheruser: correct (although it's not clear yet we fully can fix malleability)
101 2014-02-21 02:15:01 <justanotheruser> maaku: So sad :'(
102 2014-02-21 02:15:11 <justanotheruser> Why haven't I heard anything of this until recently?
103 2014-02-21 02:15:17 <justanotheruser> (recently being 2 minutes ago)
104 2014-02-21 02:15:42 <maaku> heard about what? contracts?
105 2014-02-21 02:15:52 <justanotheruser> maaku: malleability crushing my dreams
106 2014-02-21 02:16:12 <justanotheruser> ironic isn't it
107 2014-02-21 02:16:43 <njaard> gmaxwell: why is ripemd used instead of a truncated sha256?
108 2014-02-21 02:17:00 <maaku> njaard: ask satoshi not gmaxwell
109 2014-02-21 02:17:22 <njaard> <joke>Who's that</joke>
110 2014-02-21 02:17:23 <maaku> well it's exactly why there hasn't been much activity with interesting scripts & complicated transaction protocols
111 2014-02-21 02:17:58 <njaard> what do you mean?
112 2014-02-21 02:18:11 <justanotheruser> maaku: oh. I thought it was just because people didn't do it
113 2014-02-21 02:18:35 <gmaxwell> njaard: because truncation of all hash functions isn't safe, its a more conservative design to use something which has been tested in that specific construct (though truncated sha256 now looks fine)
114 2014-02-21 02:18:58 <justanotheruser> gmaxwell: any comments on this?
115 2014-02-21 02:19:02 <gmaxwell> RIPEMD160 has a greate security trackrecord.  In any case, if you want you could be using HASH256 based keys.
116 2014-02-21 02:19:14 <gmaxwell> justanotheruser: on what?
117 2014-02-21 02:19:38 <justanotheruser> 21:08 < maaku> justanotheruser: because most of the interesting application of scripts are to contracts, and malleability limits what you can do in terms of putting  stuff together off-chain
118 2014-02-21 02:19:40 <maaku> justanotheruser: a bit of both. there are interesting things that can be done now
119 2014-02-21 02:19:49 <maaku> but just aren't because no one does
120 2014-02-21 02:19:55 <maaku> no one really uses multisig even
121 2014-02-21 02:19:55 <njaard> I'm sorry I asked ;)
122 2014-02-21 02:20:13 <justanotheruser> coinswap requires a refund tx right? So tx malleability effects it?
123 2014-02-21 02:20:19 <gmaxwell> justanotheruser: maybe a bit of an exageration, malleability makes any protocol that involves precomputed refunds a little less safe and more complicated. But those protocols are already very complicated.
124 2014-02-21 02:20:35 <gmaxwell> justanotheruser: I even talked about that in the coinswap page!
125 2014-02-21 02:20:46 <justanotheruser> gmaxwell: okay, reading it again
126 2014-02-21 02:21:14 <gmaxwell> justanotheruser: you can effectively blind the refund signature using p2sh (or perhaps the new blind ECDSA) so that the exposure is pretty minimal though.
127 2014-02-21 02:21:21 <gmaxwell> but it makes it somewhat more complicated.
128 2014-02-21 02:21:23 <justanotheruser> gmaxwell: ctrl+f malleability gives me nothing
129 2014-02-21 02:21:34 <justanotheruser> gmaxwell: does it make the tx much larger?
130 2014-02-21 02:21:46 <gmaxwell> no.
131 2014-02-21 02:21:58 <justanotheruser> gmaxwell: Is it possible without protocol changes?
132 2014-02-21 02:22:07 <gmaxwell> justanotheruser: "Also note that care related to mutability is required for the refunds until transaction mutability is solved."
133 2014-02-21 02:22:13 <njaard> gmaxwell: thank you for the answer
134 2014-02-21 02:22:17 <gmaxwell> I describe how to work around it in one of the coinflip threads.
135 2014-02-21 02:22:46 <justanotheruser> gmaxwell: okay, is the workaround invulnerable?
136 2014-02-21 02:22:58 <gmaxwell> No.
137 2014-02-21 02:23:01 <gmaxwell> you just make it so that the refund uses p2sh and a nonce, so the signer doesn't know which txn is theirs... so they'd be forced to mutate all txn to try to break the refund.
138 2014-02-21 02:23:22 <justanotheruser> gmaxwell: oh, well that's not very secure at all
139 2014-02-21 02:23:45 <justanotheruser> The cost of mutating every transaction and pushing to eligus is fairly small
140 2014-02-21 02:24:02 <gmaxwell> justanotheruser: that isn't going to work.
141 2014-02-21 02:24:09 <justanotheruser> Wait, that's wrongly put, but it's still insecure for other reasons
142 2014-02-21 02:24:19 <justanotheruser> GHash.io for example
143 2014-02-21 02:26:11 <justanotheruser> gmaxwell: what's wrong with this? https://gist.github.com/sipa/8907691
144 2014-02-21 02:26:45 <gmaxwell> nothing is wrong with it, it's the plan we've been executing on— more or less— for several years now.
145 2014-02-21 02:27:11 <justanotheruser> gmaxwell: has it been accelerated at all recently?
146 2014-02-21 02:27:24 <gmaxwell> No, why would it be?
147 2014-02-21 02:27:47 <justanotheruser> gmaxwell: because mtgox made the community want it to be accelerated
148 2014-02-21 02:27:58 <gmaxwell> No, mtgox specifically asked for something entirely unrelated.
149 2014-02-21 02:28:32 <justanotheruser> gmaxwell: what? They said the flaw was malleability, and some of the community believed them, especially after the DoS
150 2014-02-21 02:28:34 <gmaxwell> Considering that they went basically a year without updating their software to stop producing invalid DER encodings— actively blocking the improvements— it's a pretty long streach to say that they want it.
151 2014-02-21 02:28:59 <gmaxwell> justanotheruser: No, they said they wanted another transaction ID, which they have now.
152 2014-02-21 02:29:25 <maaku> gmaxwell: well mtgox foibles aside, their snafu did make people care about malleability / mutated transactions
153 2014-02-21 02:29:28 <gmaxwell> They were abundantly clear on this. I'm really getting fed up with dealing with the deception and failed reading comprehension.
154 2014-02-21 02:29:32 <justanotheruser> gmaxwell: I'm not talking about what mtgox wanted, I'm talking about the community (based on /r/bitcoin)
155 2014-02-21 02:30:08 <justanotheruser> wow...
156 2014-02-21 02:30:29 <maaku> 
ACTION does the same and goes back to work

157 2014-02-21 02:32:44 <justanotheruser> "Fortunately, as we announced on Saturday we have now
158 2014-02-21 02:32:44 <justanotheruser> implemented a solution that should enable withdrawals and mitigate any issues
159 2014-02-21 02:32:46 <justanotheruser> caused by transaction malleability"
160 2014-02-21 02:52:05 <Luke-Jr> wumpus: is there any reason to have the "reuse existing address" checkbox now that we keep a history?
161 2014-02-21 03:06:03 <analogrithems> I have an odd question.  I checked my mtgox wallet in the block chain and it shows no transactions.  I asked in mtgox-chat and they said this is because it's an internal transaction.  My question is, does anyone know if other exchanges operate this way also?  Has Mtgox always done this?  Finally is this proof that they are selling bc they don't actually have?
162 2014-02-21 03:06:44 <gmaxwell> analogrithems: thats normal, expected, happens elsewhere, always been like that, etc.
163 2014-02-21 03:11:24 <analogrithems> odd, I checked coin base and vaultofsatoshi and the transactions from them both actually show up in the block chain.  Hrrm, I'll check btc-e next
164 2014-02-21 03:14:14 <gmaxwell> analogrithems: coinbase makes internal transactions externally, this has been criticized as wasteful in the past.
165 2014-02-21 03:15:54 <jgarzik> I wonder if any of the wallets adopt a model where they segregate each user's keys into their own walled garden?
166 2014-02-21 03:15:57 <analogrithems> gmazwell: do you work at gox?
167 2014-02-21 03:16:02 <jgarzik> I suppose blockchain.info does this by necessity.
168 2014-02-21 03:16:28 <jgarzik> That would imply internal service transfers would be sent externally.
169 2014-02-21 03:16:42 <analogrithems> just curious if that makes it difficult to audit if they aren't in the public space.  Also while it may be wasteful it seems like it would ease a lot of peoples concerns of liquidity
170 2014-02-21 03:17:13 <jgarzik> analogrithems, Gox is impossible to audit, without Gox's permission
171 2014-02-21 03:17:17 <jgarzik> but
172 2014-02-21 03:17:21 <jgarzik> this is off-topic for this channel
173 2014-02-21 03:17:28 <emowataji> jgarzik: would that complicate using cold storage for funds?
174 2014-02-21 03:17:46 <emowataji> jgarzik: (segregating keys and doing internal transfers externally)
175 2014-02-21 03:18:09 <jgarzik> emowataji, perhaps yes.  It can be done, with thought.
176 2014-02-21 03:19:13 <kuzetsa> tail -1000 /home/bitcoin/.bitcoin/debug.log | fgrep progress | cut -d '=' -f 7 | tail -1 is finally at 0.999349
177 2014-02-21 03:19:17 <kuzetsa> as per [18:16:46] <sipa> ok, let me know how long it takes
178 2014-02-21 03:19:18 <analogrithems> sorry for the off topic guys just trying to understand what is individual implementation vs recommended method in this wild west new world
179 2014-02-21 03:19:34 <kuzetsa> so I guess "about 4 hours" ... which is longer than I expected :(
180 2014-02-21 03:19:56 <analogrithems> is their a better channel that talks about development implementation designs?
181 2014-02-21 03:21:02 <analogrithems> working on a project that places the whole block chain into elastic search to try new search capabilities
182 2014-02-21 03:22:24 <kuzetsa> "elastic search" <-- not sure what that means
183 2014-02-21 03:22:49 <kuzetsa> http://www.elasticsearch.org/ <-- this?
184 2014-02-21 03:23:08 <k9quaint> jgarzik stole all the gox btc and gave it to the illuminatii in exchange for justin beiber tickets, but thats off topic
185 2014-02-21 03:24:37 <kuzetsa> analogrithems: if so, I'm kinda confused by the buzz word: "distributed percolations"
186 2014-02-21 03:24:55 <kuzetsa> google doesn't know what to make of it either (that term)
187 2014-02-21 03:25:36 <linagee> would it be possible to use the 80 extra bytes from bitcoin 0.9 to point to a URL with .js that nodes can run?
188 2014-02-21 03:25:46 <linagee> (sort of like ethereum script)
189 2014-02-21 03:26:04 <analogrithems> kuzetsa: yes www.elasticsearch.org
190 2014-02-21 03:26:21 <analogrithems> where did you see distributed percolations
191 2014-02-21 03:26:30 <kuzetsa> analogrithems: ok then, fine... but what are you attempting to accomplish?
192 2014-02-21 03:26:33 <linagee> or store ethereum script itself in the 80 bytes and allow chaining together multiple parts
193 2014-02-21 03:26:46 <gmaxwell> linagee: dude, please lay off the drugs.
194 2014-02-21 03:26:53 <gmaxwell> linagee: what the @#$@ are you thinking?
195 2014-02-21 03:27:03 <copumpkin> lol
196 2014-02-21 03:27:20 <linagee> gmaxwell: drinking from the ethereum wine and thinking to how it might be integrated back into bitcoin. :)
197 2014-02-21 03:27:21 <kuzetsa> analogrithems: (quote from http://www.elasticsearch.org/ ) what's new in 1.0?   snapshot & restore, distributed percolations, aggregations and more
198 2014-02-21 03:27:25 <gmaxwell> I'm sorry, I can't hear your response past the knife I just planted in your face.
199 2014-02-21 03:27:38 <linagee> gmaxwell: brutal! :(
200 2014-02-21 03:27:45 <analogrithems> oh, the es system combines nosql + Java lucene + autosharding and clustering to take very large data sets and allow you to create some really fast data search and aggregation
201 2014-02-21 03:27:45 <gmaxwell> linagee: Sorry. :P
202 2014-02-21 03:28:02 <linagee> gmaxwell: adapt or die. I'm trying to adapt.
203 2014-02-21 03:28:18 <gmaxwell> linagee: you're throughly throughly confused.
204 2014-02-21 03:28:29 <gmaxwell> So much so that I don't know what to do except set you on fire.
205 2014-02-21 03:28:30 <linagee> gmaxwell: howso?
206 2014-02-21 03:29:08 <analogrithems> Initially I'm doing this to try to get a better understanding of how bit coin works under the hood but eventually I'll be using this to create some better metrics about trading based off time, (possibly location if I can find a way to correlate it, maybe IP)
207 2014-02-21 03:29:12 <linagee> gmaxwell: am I misunderstanding that "there will be 80 extra bytes to store stuff"?
208 2014-02-21 03:29:29 <gmaxwell> linagee: because what the everlasting fuck. We have a flexible scripting system already. There aren't any "80 extra bytes", ... script rules are part of a cryptographic consensus system, you can't just glom on javascript and urls and not create complete doom.
209 2014-02-21 03:29:36 <gmaxwell> linagee: yes, you are misunderstanding.
210 2014-02-21 03:29:37 <kuzetsa> analogrithems: bitcoin protocol itself has no concept of exchange rates (so "trading" is not relevant)
211 2014-02-21 03:29:42 <gmaxwell> And misunderstanding that there would need to be
212 2014-02-21 03:29:59 <analogrithems> an example used in elastic search is that 4square uses it to track 4million locations in realtime
213 2014-02-21 03:30:07 <gmaxwell> and misunderstanding that adding javascript fetched from a URL would be at all viable and wouldn't instantly destroy the network and completely undermine its security.
214 2014-02-21 03:30:19 <gmaxwell> and misunderstanding that doing such a thing would be even slightly desirable
215 2014-02-21 03:30:30 <linagee> gmaxwell: explain the doom part. even if a small number of miners did this, it would work just fine. no need for a 50%+ consensus. you'd just get paid for executing this extra script.
216 2014-02-21 03:30:43 <linagee> gmaxwell: DAOs...
217 2014-02-21 03:31:01 <gmaxwell> and misunderstanding that we've worked very hard to avoid introducing turing completenes into script— having almost done so accidentally once— and missing that etherum has _absolutely no_ argument as to how their validation model won't end up completely insecure.
218 2014-02-21 03:31:09 <kuzetsa> analogrithems: I still have no idea what you're trying to accomplish or why
219 2014-02-21 03:31:42 <linagee> gmaxwell: please steer me away from ethereum. how would it be insecure? re: the code they run, you mean?
220 2014-02-21 03:31:45 <gmaxwell> linagee: paid for executing something accomplishes _nothing_ if you want to pay people to execute something go use EC2.
221 2014-02-21 03:31:49 <analogrithems> kuzetsa: i understand it has no concept or need for exchange rates.  I'm looking to try to see if I can get new metrics about how trades happen, where they come from and go to, which ones are doing more, which exchanges handle the most volume, from where and what time of day they happen
222 2014-02-21 03:32:33 <gmaxwell> linagee: no, because they have proposed making verifying blocks _very_ expensive, and have not proposed any way that people can get compensated from actually performing the work.
223 2014-02-21 03:32:37 <analogrithems> similarly to how blockchain.info provides limited details on whats happening when and where
224 2014-02-21 03:32:39 <kuzetsa> analogrithems: bitcoin protocol has no sense of which nodes (exchange-owned or otherwise) are the intended target for a transaction either.
225 2014-02-21 03:33:08 <gmaxwell> linagee: executing things outside of the context of consensus is pointless. Why bother? nothing then validates that its being performed correctly or not.
226 2014-02-21 03:33:14 <linagee> gmaxwell: your ethereum contracts take extra mining fee to run. or they get ignored. more code to run = higher fee.
227 2014-02-21 03:33:44 <gmaxwell> linagee: yes, which is only paid to the miner that includes them, and not anyone else. But _everyone_ must validate them, or the miner can just falsely include them.
228 2014-02-21 03:33:48 <analogrithems> kuzetsa: how are sites measuring the trade volume of the exchanges?
229 2014-02-21 03:34:36 <linagee> gmaxwell: I'm watching Vtalik (sp?) and he didn't address though - what if someone just wants to take up a lot of computing power and can spend an endless amount of money? (similar to, what if someone wants to send a trillion dust transactions on bitcoin. I guess we can just raise the dust threshold, but that seems quite evil.)
230 2014-02-21 03:34:50 <Luke-Jr> analogrithems: the blockchain is not for auditing purposes.
231 2014-02-21 03:34:59 <gmaxwell> linagee: step aside while I drop these tanks of nuclear waste in your living room, what do you mean stop? I already paid petertodd for the privledge of doing this.
232 2014-02-21 03:35:57 <analogrithems> so far I've only been working with the data from bitcond rpc interface getblock & gettransaction
233 2014-02-21 03:36:05 <kuzetsa> analogrithems: I agree with what Luke-Jr just said. analogrithems: You have some ideas I don't understand, and I have no idea what or why you're doing whatever you think you want to do.
234 2014-02-21 03:36:34 <gmaxwell> linagee: then there is the whole question of applications, we have a powerful scripting system in bitcoin which is almost completely unused. It's very powerful and no one is even suggesting things that it can't do— if they were whatever missing opcodes could be provided.
235 2014-02-21 03:36:50 <gmaxwell> linagee: which is sort of a non-existance proof about the actual usefulness of this stuff.
236 2014-02-21 03:36:54 <linagee> gmaxwell: anyone who can drum up buzz will get funded though. its a popularity game. even if the model does crumble. like altcoins and dogecoin. /me rinses mouth out from saying that word.
237 2014-02-21 03:37:07 <analogrithems> as i stated initially it's to understand bc system better, long term is to try to see what data is available to make better metrics
238 2014-02-21 03:37:21 <gmaxwell> linagee: not to mention that if you don't actually care about real security you can oracle bond any computable function into bitcoin already.. but no one has bothered.
239 2014-02-21 03:37:56 <kuzetsa> analogrithems: why do you want metrics?
240 2014-02-21 03:37:58 <linagee> gmaxwell: I do agree with that. but how do you provide unencrypted data to the recipient?
241 2014-02-21 03:38:15 <kuzetsa> analogrithems: metrics for //what// exactly are you after?
242 2014-02-21 03:38:19 <gmaxwell> linagee: yea sure, I do get that. But if you want to fight hopepumping you can't do so with technology. No one completely honest will ever be able to compete with the marking pumping of someone not so constrained.
243 2014-02-21 03:38:39 <gmaxwell> linagee: can you try phrasing that question another way?
244 2014-02-21 03:39:38 <analogrithems> personally I'm just curious about what all this looks like when it's graphed.  I'm a bit of a math nerd.  Is anyone ever curious how much money is spent on a given day on transaction fees?
245 2014-02-21 03:39:57 <linagee> gmaxwell: if I want to have a service where I add 2+2 for you, just send money to my bitcoin address, how do I provide a result?
246 2014-02-21 03:40:00 <analogrithems> what about what is the avg confirmation time?
247 2014-02-21 03:40:38 <analogrithems> also with regard to confirmations does the block chain record who does the confirmations?  Is there a way to see who does most of the confirmations?
248 2014-02-21 03:41:11 <linagee> analogrithems: blockchain.info provides this. (ie, which mining pool does the transaction)
249 2014-02-21 03:41:13 <kuzetsa> analogrithems: confirmations are nothing more than a transaction being stored in the blockchain, and how deep it is in the chain
250 2014-02-21 03:41:17 <justanotheruser> analogrithems: the blockchain doesn't record who generates blocks. Blockchain.info tries to, but it's not guaranteed to be accurate
251 2014-02-21 03:41:42 <gmaxwell> linagee: that isn't what etherum does in any case... everyone executes the script, including the party thta created it... though what you are asking for can actually be done in Bitcoin. https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
252 2014-02-21 03:41:54 <linagee> justanotheruser: exactly. they are just a third party making a best-effort attempt.
253 2014-02-21 03:42:38 <kuzetsa> linagee: are you now talking about the thing with confirmations which analogrithems was asking about?
254 2014-02-21 03:43:00 <kuzetsa> or ... wanting to measure "better-ly" or something
255 2014-02-21 03:43:03 <kuzetsa> I'm really not sure
256 2014-02-21 03:43:09 <justanotheruser> gmaxwell: Does etherum have the malleability exploit we were just discussing?
257 2014-02-21 03:43:29 <analogrithems> is the blockchain.info code open sourced?
258 2014-02-21 03:43:31 <justanotheruser> By that I mean, can it do Zero Knowledge Contingent payments without a problem
259 2014-02-21 03:43:35 <gmaxwell> justanotheruser: it doesn't really exist so it's not really a meaningful question.
260 2014-02-21 03:43:37 <linagee> gmaxwell: many people *could* do the computation though. send payment to a known dust address (using a seed or something), provide your computation in the "unencrypted form" I was previously talking about. The reward of the computation is bitcoins sent back to the address who solved your problem for you.
261 2014-02-21 03:43:50 <justanotheruser> gmaxwell: good point
262 2014-02-21 03:43:55 <kuzetsa> analogrithems: much of it is (open source, yes)
263 2014-02-21 03:44:19 <kuzetsa> analogrithems --> https://github.com/blockchain
264 2014-02-21 03:44:20 <gmaxwell> linagee: sure but you can do this in bitcoin today.   OP_1 OP_1 OP_ADD OP_EQUALS  tada.
265 2014-02-21 03:44:35 <kuzetsa> analogrithems: some of their business model / backend stuff might not be open soruce though
266 2014-02-21 03:44:47 <gmaxwell> but its stupid because its not zero-knoweldge, just like it wouldn't be zero-knoweldge in etherum, meaning anyone who saw the execution could steal the result.
267 2014-02-21 03:45:03 <gmaxwell> and insanely waseful, since all nodes must repeat the computation.
268 2014-02-21 03:45:07 <linagee> gmaxwell: that's neat, but I actually meant like the opcodes ethereum has. (the 60 or whatnot.) if they are all there (or even most), then its definitely something I'm interested in
269 2014-02-21 03:45:10 <gmaxwell> but they don't get paid for it.
270 2014-02-21 03:45:37 <analogrithems> also the information returned from getblock & gettransaction is that the complete information that is stored in the block chain or is there more?
271 2014-02-21 03:45:58 <linagee> gmaxwell: I get it. so you'd want a consensus. not a random answer. not sure if that's what ethereum is doing or not...
272 2014-02-21 03:46:04 <gmaxwell> linagee: You've not actually described an actual application, I think you're basically being defrauded by careless marketing by the Etherum team.
273 2014-02-21 03:46:17 <justanotheruser> gmaxwell: Could you explain what part of tx malleability might not be fixable? I'm reading the github on how to supposedly fix it.
274 2014-02-21 03:46:17 <linagee> :(
275 2014-02-21 03:46:36 <gmaxwell> justanotheruser: I have no clue what you're talking about.
276 2014-02-21 03:46:47 <linagee> gmaxwell: have you taken a look at their subcurency CLL?
277 2014-02-21 03:47:22 <justanotheruser> gmaxwell: 21:14 < maaku> justanotheruser: correct (although it's not clear yet we fully can fix malleability)
278 2014-02-21 03:47:47 <gmaxwell> justanotheruser: because we have no proof that there isn't additional algebraic malleability in DSA beyond the amount we know about already.
279 2014-02-21 03:48:01 <gmaxwell> though it seems likely that there isn't.
280 2014-02-21 03:48:14 <linagee> https://github.com/jorisbontje/cll-sim/blob/master/examples/subcurrency.cll    compiles to these opcodes: http://pastebin.com/sBpN6pG5
281 2014-02-21 03:48:29 <justanotheruser> gmaxwell: I see. Is it possible to prove that there isn't malleability?
282 2014-02-21 03:49:23 <gmaxwell> Probably. Though its not trivial.
283 2014-02-21 03:49:24 <justanotheruser> s/isn't/isn't additional
284 2014-02-21 03:49:27 <linagee> gmaxwell: I do suspect ethereum of using sockpuppet accounts to make their project look larger than it actually is. pretty clever though.
285 2014-02-21 03:49:37 <gmaxwell> andytoshi has created a proof for schnorr which I buy.
286 2014-02-21 03:50:13 <justanotheruser> gmaxwell: Is schnorr easier?/
287 2014-02-21 03:50:26 <justanotheruser> Damn, I've got to learn to ask question.
288 2014-02-21 03:50:43 <justanotheruser> Is it easier to make such a proof for schnoor?
289 2014-02-21 03:50:44 <gmaxwell> justanotheruser: yes, its much easier to analyize... which is why there are security proofs for it and few/none for dsa.
290 2014-02-21 03:52:15 <kuzetsa> I sure hope that blockchain data reindex (re-creating fresh non-bloated / non-corrupt rev???? files) didn't hurt anyone else's performance on anyone else's instance on this xen node O_O
291 2014-02-21 03:53:47 <kuzetsa> sipa: again, thanks. it took less than 5 hours from the time I deleted the rev???? files, realized I might crash without them & proceded to reindex and whatnot
292 2014-02-21 03:54:19 <gmaxwell> kuzetsa: I'm glad you got sorted.
293 2014-02-21 03:54:30 <kuzetsa> if I end up having to do it again I'll see if I can reboot the xen instance with more ram for a few hours (I'm pretty sure it's prorated by the datacenter if I do that and then step back down to the 1 gig ram tier)
294 2014-02-21 03:55:08 <kuzetsa> like I think some sort of cache option was recommended to speed up the reindex, but I can't remember the exact command line flag
295 2014-02-21 03:55:43 <kuzetsa> dbcache maybe?
296 2014-02-21 03:56:14 <kuzetsa> is there an upper limit to how much ram I might throw at it before I get diminishing returns for performance gains?
297 2014-02-21 03:57:13 <kuzetsa> and/or maybe is there a lower limit so that I might've done it with just the ram I had available since this server isn't used for hardly anything other than a stable long-running well-connected bitcoin node
298 2014-02-21 03:58:10 <kuzetsa> I'm not likely to enable it 24/7 since I also use it as my build environment for various binary packages for ... science or something O_O
299 2014-02-21 04:52:29 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/3716
300 2014-02-21 04:55:01 <freewil> Luke-Jr: do you still have that webpage up that shows the breakdown of nodes by version?
301 2014-02-21 04:55:08 <Luke-Jr> yes
302 2014-02-21 04:55:20 <Luke-Jr> http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
303 2014-02-21 04:55:25 <freewil> thanks
304 2014-02-21 05:19:28 <Michail1> bitcoin in ProcessMessages()
305 2014-02-21 05:19:28 <Michail1> EXCEPTION: St9bad_alloc
306 2014-02-21 05:19:28 <Michail1> std::bad_alloc
307 2014-02-21 05:19:30 <Michail1> Ideas?
308 2014-02-21 05:23:29 <maaku> analogrithems: this is a perfectly fine channel for talking about recommended procedures for wallet authors
309 2014-02-21 05:23:43 <maaku> just not the "why does gox do it this way?" questions - we're not gox support
310 2014-02-21 05:28:23 <gmaxwell> Michail1: 32 bit system? what bitcoin version?
311 2014-02-21 05:30:00 <Michail1> raspberry pi.   bitcoind   0.8.6
312 2014-02-21 05:30:18 <Luke-Jr> LOL
313 2014-02-21 05:30:21 <Michail1> :)
314 2014-02-21 05:30:48 <Michail1> Come on Luke-Jr, you know you're jealous.  :)
315 2014-02-21 05:32:47 <Luke-Jr> of a poorly performing SBC with known hardware flaws, running probably the most proprietary architecture ever?
316 2014-02-21 05:34:10 <Michail1> yes, that.  :)
317 2014-02-21 05:35:42 <Luke-Jr> Michail1: your question wasn't serious, I presume?
318 2014-02-21 05:36:24 <Michail1> Well, restarted bitcoind and it's working.  Has passed that block.  So, ETA to reindex is 9+ days..... The question with regards to the error was serious since I don't know what it was and couldn't find with google.
319 2014-02-21 05:36:35 <Luke-Jr> …
320 2014-02-21 05:36:53 <Luke-Jr> Michail1: there is about zero chance bitcoind will run on a RPi.
321 2014-02-21 05:37:52 <Michail1> zero chance?  Strange, I have it running on 4x pis now; hoever, haven't given them time to index completely.  Highest one is at 274100 blocks.
322 2014-02-21 05:38:23 <Luke-Jr> Michail1: at this time, it essentially requires a 64-bit computer
323 2014-02-21 05:39:13 <Michail1> So, it will fail at a certain block and stop, or do you mean it will just be very very slow?
324 2014-02-21 05:39:27 <Luke-Jr> you'll probably see std::bad_alloc again
325 2014-02-21 05:39:34 <Luke-Jr> that error essentially means "out of memory"
326 2014-02-21 05:40:12 <Michail1> Ahhh, thanks.   So, restarting will resolve assuming it doesn't corrupt chainstate/index.
327 2014-02-21 05:41:34 <justanotheruser> So would a fix to the malleability of ECDSA be a softfork?
328 2014-02-21 05:43:15 <Luke-Jr> justanotheruser: yes; but you'd need to study it in advanced maths to prove you even *can* fix it
329 2014-02-21 05:46:28 <justanotheruser> Luke-Jr: Can you estimate how much money would need to be thrown at the problem to prove whether you can fix it?
330 2014-02-21 05:46:41 <Luke-Jr> no
331 2014-02-21 05:47:16 <Luke-Jr> if I had to guess, I'd say an accurate estimate is as much work as actually doing it. but I don't have enough math background to know for sure if that's true or not.
332 2014-02-21 05:52:23 <justanotheruser> Do people generally pay PhD students for this kind of thing?
333 2014-02-21 05:53:05 <gmaxwell> andytoshi's been working on it. Not sure if he's made any headway on ECDSA though he did appear to produce a reasonable proof for schnorr.
334 2014-02-21 05:54:14 <gmaxwell> justanotheruser: this is something that you don't have to be an uber math wiz to attempt. Since generally regular algebra rules apply. Probably getting more people attempting it will be helpful.
335 2014-02-21 05:56:28 <maaku> gmaxwell: also, it is in principle possible to soft-fork to use schnorr or lamport signatures, or something else which is proven non-malleable
336 2014-02-21 05:56:38 <maaku> and in both those cases there would be reasons to do so anyway
337 2014-02-21 05:56:58 <maaku> (compact multisig and quantum resistance, respectfully)
338 2014-02-21 05:58:03 <gmaxwell> not just quantum resistance. "Assumption resistant" since lamports only need a strong hash, while all other schemes need a strong hash plus some other assumption. (e.g. hardness of discrete log in some EC group)
339 2014-02-21 06:04:44 <maaku> BlueMatt: if I rebase a pull request, do I need to do anything to get the pull tester to try it again?
340 2014-02-21 06:05:02 <gmaxwell> I'm pretty sure it will just run again.
341 2014-02-21 06:16:58 <maaku> gah now i have to find out why mingw doesn't support the POSIX function ffs
342 2014-02-21 06:17:07 <maaku> - wait, i think I just did :)
343 2014-02-21 06:18:18 <Luke-Jr> jgarzik: re IPC; if it can be reduced to a single channel, we have stdio portably
344 2014-02-21 06:18:42 <Luke-Jr> maaku: you do know Windows is not POSIX-compatible, right? ;)
345 2014-02-21 06:18:52 <Luke-Jr> maaku: and MinGW is not a POSIX layer
346 2014-02-21 06:22:17 <uiop> maaku: it may be helpful that gcc has __builtin_ffs(..)
347 2014-02-21 06:24:36 <uiop> Luke-Jr: or you can just carry around a pair of FILE*'s
348 2014-02-21 06:25:58 <uiop> (although i couldn't find jgarzik's remark(s) that you're referring to, so i'm speaking with no context)
349 2014-02-21 06:26:28 <maaku> Luke-Jr: that was my smiley
350 2014-02-21 06:26:41 <Luke-Jr> uiop: -dev ML
351 2014-02-21 06:27:09 <uiop> ah, i've been meaning to start reading that..
352 2014-02-21 06:27:18 <maaku> uiop: i was hoping to avoid gcc dependency
353 2014-02-21 06:28:11 <jgarzik> uiop, http://sourceforge.net/p/bitcoin/mailman/message/32006864/
354 2014-02-21 06:30:10 <Luke-Jr> maaku: static inline int ffs(const int i) { unsigned long rv; return _BitScanReverse(&rv, i) ? rv : 0; }
355 2014-02-21 06:31:25 <uiop> maaku: #define FFS(a)({uint64_t __b; asm("movq $64, %0\n\t" "bsf %1, %0" :"=r"(__b) :"r"(a)); __b;}) /* :) */
356 2014-02-21 06:31:34 <wumpus> ah the good old ffs function :)
357 2014-02-21 06:31:46 <Luke-Jr> uiop: that won't work on MIPS
358 2014-02-21 06:31:53 <uiop> Luke-Jr: heh
359 2014-02-21 06:32:22 <wumpus> I thought the mesa codebase was swearing when I first encountered it
360 2014-02-21 06:32:41 <maaku> uiop: architecture dependency is worse than compiler dependency :)
361 2014-02-21 06:33:10 <uiop> maaku: i couldn't find the C version in my files, so gave up the search and punted ;)
362 2014-02-21 06:34:57 <maaku> _BitScanReverse is probably the best option on mingw32
363 2014-02-21 06:35:16 <maaku> unfortunately I can't inline it because of a circular header dependency :(
364 2014-02-21 06:36:33 <Luke-Jr> Don't Do That™
365 2014-02-21 06:36:34 <gmaxwell> there is a fast CLZ implementation in C (plus ifdefs for BSR in gcc and msvc) in the opus codebase
366 2014-02-21 06:38:07 <maaku> thanks gmaxwell, I'll look at that
367 2014-02-21 06:38:10 <maaku> Luke-Jr: don't do what?
368 2014-02-21 06:39:18 <Luke-Jr> circular header :P
369 2014-02-21 06:40:30 <maaku> ah well what I meant was this stuff would logically go in util.h, but I need to use it in uint256.h, which util.h includes
370 2014-02-21 06:41:09 <uiop> ah, found BSR (and POPCOUNT) http://pastebin.com/wCD0d70P
371 2014-02-21 06:41:29 <uiop> iirc bsf (ffs) can do w/out the popcount
372 2014-02-21 06:41:37 <Luke-Jr> maaku: implement uint256::ffs! :P
373 2014-02-21 06:41:42 <uiop> and it's almost identical to the bsr code
374 2014-02-21 06:50:05 <uiop> Luke-Jr: ah just saw your link, thx
375 2014-02-21 06:50:28 <uiop> err, i meant jgarzik, thx
376 2014-02-21 06:53:43 <jgarzik> wumpus, I'll hack out getwalletinfo before bed
377 2014-02-21 06:54:12 <jgarzik> 
ACTION curses leveldb for not having a clean build, like we do

378 2014-02-21 06:54:52 <uiop> sqlite has a clean build :)
379 2014-02-21 06:55:27 <wumpus> jgarzik: #3717 was already updated to add it
380 2014-02-21 06:58:17 <jgarzik> wumpus, heh, that was fast.  Looks like he did the right thing, and copied over all the wallet items from 'getinfo'
381 2014-02-21 06:59:16 <wumpus> jgarzik: yes looks good to me too
382 2014-02-21 07:02:47 <jgarzik> wumpus, except for the whole "doesn't compile" thing anyway ;p
383 2014-02-21 07:02:58 <jgarzik> little details
384 2014-02-21 07:03:55 <wumpus> oh yes it should at least pass the pull tester
385 2014-02-21 07:07:06 <justanotheruser> Does anyone have complicated example scripts?
386 2014-02-21 07:07:30 <Luke-Jr> sure
387 2014-02-21 07:07:35 <Luke-Jr> testnet is full of them
388 2014-02-21 07:08:10 <justanotheruser> Luke-Jr: Good suggestion
389 2014-02-21 07:10:59 <justanotheruser> Still is pretty tough to find interesting tx
390 2014-02-21 07:13:37 <jgarzik> <petertodd> Oh, and tighten up the definition of OP_PUBKEY(s) in Solver() while you're at it to only 33 bytes or 65 bytes - current allows up to 120 bytes for no good reason.
391 2014-02-21 07:13:45 <jgarzik> tempting
392 2014-02-21 07:14:11 <jgarzik> make >33 non-standard
393 2014-02-21 07:14:52 <wumpus> wouldn't a compromise for OP_RETURN also be to allow 32 at most? why do we allow 80?
394 2014-02-21 07:14:58 <maaku> jgarzik: wouldn't that break non-compressed pubkey addresses?
395 2014-02-21 07:15:15 <maaku> wumpus: design by committee?
396 2014-02-21 07:15:46 <jgarzik> wumpus, 2x 256-bit hash or 1x SHA512 hash + some extra for type specifiers
397 2014-02-21 07:15:56 <wumpus> as @gmaxwell said a few days ago 32 would be enough to store any kind of hash within the security parameters of bitcoin itself
398 2014-02-21 07:16:07 <jgarzik> maaku, it would make uncompressed non-standard
399 2014-02-21 07:16:34 <gmaxwell> making uncompressed non-standard in v3 txn is attractive.
400 2014-02-21 07:16:42 <wumpus> maaku: yes I meant a compromise between the people that want to disable it commpletely and those that want it enabled
401 2014-02-21 07:16:45 <gmaxwell> (not forbidden just non-standard)
402 2014-02-21 07:16:51 <jgarzik> nod
403 2014-02-21 07:17:06 <maaku> jgarzik: what I mean is, I can't control whether someone sends me money using one of my old uncompressed addresses
404 2014-02-21 07:17:43 <jgarzik> wumpus, existing sketches and some not-widely-deployed code does stuff like "BOND" + hash, to enable easy, decentralized public auditing
405 2014-02-21 07:17:49 <maaku> it'd be annoying if there were no way to spend it in a relayable transaction
406 2014-02-21 07:25:33 <wumpus> maaku: what is the idea behind thia base-32 encoding (#3713), to replace base-58?
407 2014-02-21 07:30:03 <jgarzik> maaku, a fair point
408 2014-02-21 07:30:29 <Luke-Jr> maaku: you can refuse to accept it as payment
409 2014-02-21 07:30:43 <gmaxwell> wumpus: at least the way I understood it is that its an alterntive encoding that might be better than base58check for some future things.
410 2014-02-21 07:30:50 <Luke-Jr> maaku: unless you tell them to send it there, they have no reasonable expectation that you can access it
411 2014-02-21 07:31:17 <Luke-Jr> maaku: did you see my earlier base32 encoding suggestion btw?
412 2014-02-21 07:31:26 <jgarzik> Luke-Jr, while true, I can see a situation out there, somewhere, where an unfortunate user is trapped by this decision unknowningly
413 2014-02-21 07:31:50 <gmaxwell> sadly we can't catch cases of it in scriptpubkeys usefully.
414 2014-02-21 07:31:51 <wumpus> gmaxwell: for addresses I prefer error detection to error correction, I'd rather be reminded that I typed/copypasted something wrong and make my own correction than have the algorithm do it maybe the wrong way around
415 2014-02-21 07:32:15 <Luke-Jr> maaku: http://bitcointroll.org/?topic=205878
416 2014-02-21 07:32:19 <wumpus> maybe it's different for privkeys
417 2014-02-21 07:32:20 <gmaxwell> wumpus: a valid usecase for this would be disabling the correction and getting stronger detection as a result.
418 2014-02-21 07:32:20 <jgarzik> wumpus, +100
419 2014-02-21 07:32:35 <jgarzik> 
ACTION also strongly dislikes error correction

420 2014-02-21 07:32:38 <gmaxwell> wumpus: a key point is that having correction _possible_ doesn't make detection worse.
421 2014-02-21 07:33:01 <wumpus> gmaxwell: well then I have nothing against using it with correction disabled
422 2014-02-21 07:33:29 <gmaxwell> (I fully agree on that, btw, and NAKed luke's old patch to fix non-base58 characters for that reason.  Though for some things correction probably makes sense at least to have available)
423 2014-02-21 07:33:41 <gmaxwell> also, base 58 is a @#$@#$ @$#@$@# to _read_ because of the mixed case.
424 2014-02-21 07:33:50 <wumpus> the current 32-bit 'checksum' may not be thorough enough
425 2014-02-21 07:33:56 <jgarzik> gmaxwell, true dat
426 2014-02-21 07:34:18 <wumpus> indeed, the mixed case is annoying
427 2014-02-21 07:34:31 <gmaxwell> I've done trades a couple of times involving reading bitcoin addresses, I'm pretty confortable reading data, but the mixed case has always tripped me up.
428 2014-02-21 07:34:50 <Luke-Jr> 
ACTION also

429 2014-02-21 07:34:58 <jgarzik> if you change the bitcoin address format, add some hyphens or space periodically
430 2014-02-21 07:35:19 <maaku> Luke-Jr: no, i hadn't seen it yet
431 2014-02-21 07:35:33 <maaku> gtw, i found boost::heap::detail::log2 which looks like the best solution
432 2014-02-21 07:35:34 <Luke-Jr> maaku: maybe some ideas to borrow in it
433 2014-02-21 07:35:43 <wumpus> can we rename address to 'one-time payment key id' at the same time? :)
434 2014-02-21 07:36:00 <gmaxwell> the bummer about the base32 stuff is that its rather long.
435 2014-02-21 07:36:04 <Luke-Jr> wumpus: "invoice id" is so much shorter :P
436 2014-02-21 07:36:12 <wumpus> Luke-Jr: yes that's even better
437 2014-02-21 07:36:19 <wumpus> Luke-Jr: I just mean, everything but address really
438 2014-02-21 07:36:24 <Luke-Jr> hehe
439 2014-02-21 07:36:35 <Luke-Jr> gmaxwell: we can throw in P2SH^2 at the same time :P
440 2014-02-21 07:36:41 <gmaxwell> I'm also skeptical that maaku's CRC approach is really all that much simpler than a 6 bit RS code, but don't have time to go implement the alternative for comparison.
441 2014-02-21 07:37:02 <gmaxwell> gah. 5 bit, I don't know why I keep thinking 6 bit.
442 2014-02-21 07:37:02 <wumpus> and inserting hyphens is a good idea too - having seperate groups makes it easier to distinguish visually
443 2014-02-21 07:37:53 <Luke-Jr> wumpus: underscores if we want to appease the "double-click must highlight it all" crowd :p
444 2014-02-21 07:38:01 <wumpus> though those should be optional and just part of the visual representation, not enforced
445 2014-02-21 07:38:35 <wumpus> Luke-Jr: but is that so important? people use spaces between IBAN numbers for example
446 2014-02-21 07:38:44 <Luke-Jr> wumpus: dunno
447 2014-02-21 07:38:57 <Luke-Jr> reminder: hopefully addresses will die soonish anyway? :P
448 2014-02-21 07:39:18 <gmaxwell> not likely. :(
449 2014-02-21 07:39:18 <Luke-Jr> wumpus: besides, who uses IBAN numbers? O.o
450 2014-02-21 07:39:32 <wumpus> Luke-Jr: everyone here in europe?
451 2014-02-21 07:39:33 <gmaxwell> PP is not a replacement for a huge swath of how bitcoin is used.
452 2014-02-21 07:39:48 <Luke-Jr> wumpus: I see.
453 2014-02-21 07:39:53 <wumpus> Luke-Jr: we use IBANS for every bank transfer now
454 2014-02-21 07:39:58 <wumpus> even within the country
455 2014-02-21 07:40:06 <Luke-Jr> bank transfers are very rare in the US
456 2014-02-21 07:40:15 <Luke-Jr> outside of things like checks
457 2014-02-21 07:40:15 <maaku> wumpus: the impetus was as an improvement to "helpdesk identifiers" like the proposed ntxid, but it's designed to be useful as a replacement for base58 as well
458 2014-02-21 07:40:26 <Luke-Jr> and debit cards
459 2014-02-21 07:40:37 <maaku> of course I don't expect to actually replace base58 for addresses, but if someone is designing something new...
460 2014-02-21 07:42:02 <jgarzik> credit card numbers use spaces. phone numbers and SSNs use dashes, or more recently, periods.
461 2014-02-21 07:42:02 <maaku> wumpus: how is error correction worse than error detection? with correction you know or can be told where the error is, and go back to verify
462 2014-02-21 07:42:21 <jgarzik> I would use a space or hyphen, matching existing popular systems.
463 2014-02-21 07:42:25 <maaku> underscores unfortunately don't work on all browsers for click-to-select
464 2014-02-21 07:42:53 <Luke-Jr> maaku: lolwut? underscore is \w
465 2014-02-21 07:43:09 <wumpus> maaku: I wouldn't like error correction for addresses or other IDs that are used in non-reversible operations -- that's just a personal preference
466 2014-02-21 07:43:28 <gmaxwell> ADl3j2q7hg_hlrk0pxcbb_4pchq1flmh_7w4cz8s0g8_98r4q713hx_hfm8grwzkr  I guess that isn't so bad as an address sort of thing.
467 2014-02-21 07:44:00 <gmaxwell> maaku: what sparsification of 36->32 are you using? (I just left out aeio because vowels and io are somewhat ambigious)
468 2014-02-21 07:44:08 <maaku> wumpus: the point is instead of "you typed something wrong." the UI could instead say "did you mean a u instead of a y for digit 12 (highlighted in red)?"
469 2014-02-21 07:44:30 <maaku> gmaxwell: z-base-32
470 2014-02-21 07:44:52 <maaku> http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt
471 2014-02-21 07:45:11 <gmaxwell> maaku: I've had problems in the past with base32/base36 encodings where "fuckyou" is possible.
472 2014-02-21 07:46:16 <wumpus> so even more vanity bullshit
473 2014-02-21 07:46:21 <maaku> gmaxwell: meh, i prefer to think internationally - there's no way we'd be able to outlaw that for all languages
474 2014-02-21 07:47:14 <gmaxwell> maaku: getting zotted by automatic filtering is kinda lame though.
475 2014-02-21 07:47:40 <gmaxwell> esp with the scunthorpe proble,
476 2014-02-21 07:47:42 <gmaxwell> er problem
477 2014-02-21 07:48:21 <wumpus> maaku: okay that could be useful; though, in practice, finding the 12th digit is almost as much work as just re-checking all the previous digits as well
478 2014-02-21 07:48:36 <wumpus> gmaxwell: what would be the solution to that? a non-alphabetical encoding?
479 2014-02-21 07:48:41 <gmaxwell> maaku: I'd suggest UI wise that you not actually tell them the correct digit, just the position.
480 2014-02-21 07:48:50 <gmaxwell> (in order to avoid dilluting the checking power)
481 2014-02-21 07:49:17 <wumpus> maaku: but yes for the UI it can be useful indeed
482 2014-02-21 07:49:24 <maaku> gmaxwell: true
483 2014-02-21 07:49:42 <gmaxwell> wumpus: the normal fix is to leave out vowels. Which as maaku points out is not entirely language neutral (but works better than you might guess, esp since a lot of filtering— even world wide— is english centric.)
484 2014-02-21 07:50:56 <maaku> well leaving out (most) vowels gets sufficient coverage, but at the cost of adding very confusing / confused combinations of characters (e.g. 1 and L)
485 2014-02-21 07:51:25 <wumpus> even a fully numeric encoding could generate combinations that may be seen as 'profane' by some filters
486 2014-02-21 07:52:03 <maaku> gmaxwell: what's an apples-to-apples comparison for RS bits?
487 2014-02-21 07:52:10 <maaku> i calculated that somehwere but can't find it
488 2014-02-21 07:52:16 <gmaxwell> it's certantly impossible to fully thawrt stupidity. Though the bleeding can be reduced.
489 2014-02-21 07:53:52 <warren> 
ACTION adds that to the gmaxwell quote bank.

490 2014-02-21 07:53:52 <wumpus> but yes, leaving out vowels seems like a good compromise
491 2014-02-21 07:54:53 <gmaxwell> maaku: if the RS is implemented over GF(2^32) you get  check-digits/2 unknown position corrections, or check-digits known position corrections.  Though you are limited to 32 digits (including checks) in a coding group.
492 2014-02-21 07:55:52 <gmaxwell> (IIRC though you can get check-digits worth of corrections with unknown positions with high probablity if you can use list-decoding)
493 2014-02-21 07:57:05 <gmaxwell> If your errors are IID at the word size level and boundary (e.g. each digit has a independant and equal chance of being either right or entirely wrong) you also get optimal error detection, no other coding scheme (of the same codeword size) can have higher performance.
494 2014-02-21 07:57:45 <maaku> so 56 digits instead of 62 for a 256-bit number
495 2014-02-21 07:58:03 <maaku> i must have done my math wrong because that's better than I thought
496 2014-02-21 07:58:28 <maaku> though the reason for CRC was that Reed Solomon has way, way more complex error correction code
497 2014-02-21 07:59:09 <maaku> you're limited to 31 digits per group, right?
498 2014-02-21 07:59:14 <gmaxwell> It _should_ be possible to have a relatively compact table based implementation. Obviously the encode can and thats basically trivial.
499 2014-02-21 07:59:46 <maaku> wait, that math is wrong. you can't really leave out digits from a group with RS, can you?
500 2014-02-21 08:00:11 <maaku> wait, n/m, I'm tired; of course you can
501 2014-02-21 08:00:19 <maaku> they just take on known (zero) values
502 2014-02-21 08:00:23 <wumpus> do keep in mind that alternate implementations need to implement this as well, so making the encoding very complex will introduce a lot of extra work overall
503 2014-02-21 08:00:46 <maaku> wumpus: that's why I went with CRC polynomials
504 2014-02-21 08:01:06 <gmaxwell> wumpus: encoding is trivial, its the error correcting decode which is potentially complex.
505 2014-02-21 08:01:06 <maaku> significantly less space efficient, but trivially simple to implement
506 2014-02-21 08:01:38 <maaku> error *detection* for reed solomon isn't as complicated though
507 2014-02-21 08:01:40 <gmaxwell> considering that base58 check is actually a pretty big PITA, I don't think any of this compares poorly.
508 2014-02-21 08:01:48 <wumpus> gmaxwell: with 'encoding' I mean the representation, including getting from and to it
509 2014-02-21 08:02:14 <gmaxwell> yea, error _detection_ for RS is the same complexity as the encode.  (you just reencode the decoded values and check)
510 2014-02-21 08:02:28 <maaku> wumpus: with RS, there are three operations: encoding, decoding with error detection, decoding with error correction - only the last is hard
511 2014-02-21 08:02:39 <wumpus> yes base58 was a bad choice in retrospect, and also complex, but people have crossed that bridge already
512 2014-02-21 08:02:40 <maaku> with CRC they are all easy, but space performance is poor
513 2014-02-21 08:03:16 <gmaxwell> I'm still skeptical that can't be made easy for a small fixed field, but I'd need to go implement it to describe a easy implementation.
514 2014-02-21 08:03:22 <maaku> (5 check digits per 26 digits imput, total group size of 31 for CRC, 2 check digits per 29 digits input, total group size of 31 for RS)
515 2014-02-21 08:03:34 <wumpus> for easy implementation it could have been just <hexid><checksum> concatenated
516 2014-02-21 08:04:29 <maaku> for detection, yes, correction is never that easy
517 2014-02-21 08:04:50 <gmaxwell> maaku: we might want to coordinate with tor and see if they are interested in a new encoding for their NG hidden service stuff. (they will be increasing key sizes from 80 bits to 256ish bits)
518 2014-02-21 08:05:32 <maaku> gmaxwell: yes, that's a good idea
519 2014-02-21 08:05:34 <gmaxwell> wumpus: all the encodings I think we'd consider would be logically <id><checksum> on a digit boundary level.
520 2014-02-21 08:06:21 <maaku> gmaxwell: and if you can find the time, a 5-bit RS coder would be interesting to see
521 2014-02-21 08:06:53 <maaku> i don't think i will have time to write something like that for at least a month
522 2014-02-21 08:07:17 <wumpus> gmaxwell: which would be enough IMO, no need for fancy error correction
523 2014-02-21 08:08:14 <gmaxwell> wumpus: The nice thing is to have an encoding where fancy is possible where it would make sense. E.g. I think for private keys thats a nice extra bit of insurance.
524 2014-02-21 08:08:27 <wumpus> just imagine the horror that whatever you are thinking up, people will end up implementing in PHP
525 2014-02-21 08:08:29 <maaku> gmaxwell: an optimal RS coder wouldn't have the same error detection limits though would it?
526 2014-02-21 08:09:15 <gmaxwell> maaku: Can you clarify the question?
527 2014-02-21 08:09:30 <wumpus> gmaxwell: storing the wallet / private keys in something that supports error correction would be very nice, though I'm not sure that you want to use error correction on a single key level in that case
528 2014-02-21 08:10:20 <gmaxwell> wumpus: well for storage you really want a different scheme because usually whole disk sectors are trashed at once.  Having an encoding for a private key have correction is handy if, e.g. you print out the keys.
529 2014-02-21 08:10:35 <maaku> gmaxwell: the chance that more than one error in a group will result in a false negative in the error detector (either pass, or register as one correctable error)
530 2014-02-21 08:10:48 <wumpus> but even in the case of printing, an 'attack' may wipe a whole region of your document
531 2014-02-21 08:10:50 <maaku> for the CRC polynomial I coded up, the rate is approx 2^-25
532 2014-02-21 08:11:50 <maaku> for 5-bit RS it would be 2^-5, right? you'd probably have to include some other sort of error detection
533 2014-02-21 08:11:54 <wumpus> in any case, yes for private keys it's different...
534 2014-02-21 08:12:15 <gmaxwell> maaku: if you only have one check digit. per group.
535 2014-02-21 08:13:34 <maaku> I'm assuming two for apples-to-apples parity (one correctable digit), so yes approx 2^-10
536 2014-02-21 08:13:35 <gmaxwell> maaku: the limit of GF(2^5) is indeed interesting and might suggest that this ought to use a concatenated code, and that would make a good error correcting decoder more complicated. I'll thing about that some.
537 2014-02-21 08:19:47 <mrkent> gmaxwell, can the malleability actually result in theft?
538 2014-02-21 08:20:27 <gmaxwell> mrkent: No.  You can creat a theft situation which involves malleability plus other mistakes, but thats true for lots of things.
539 2014-02-21 08:20:28 <maaku> mrkent: not without some other money-losing mistake
540 2014-02-21 08:20:56 <gmaxwell> mrkent: basically IF you reissue transactions without double spending inputs then you will sometimes double pay people (with or without malleability)
541 2014-02-21 08:21:02 <mrkent> Does the malleable transaction eventually go through?
542 2014-02-21 08:21:21 <maaku> mrkent: only one copy will go through
543 2014-02-21 08:21:34 <maaku> *only one mutant
544 2014-02-21 08:21:41 <gmaxwell> But if you were doing that horribly dumb thing, malleability may help the bad outcome happen.
545 2014-02-21 08:21:43 <mrkent> What I heard is that gox will send a new transaction if the first withdraw was mutated
546 2014-02-21 08:22:11 <maaku> mrkent: yes, which is a money-losing mistake on their part that has nothing to do with malleability
547 2014-02-21 08:22:15 <gmaxwell> mrkent: what mtgox was apparently doing is if a transaction didn't go through in 12 (?) hours they would automatically generate a new one and not double spend the original.
548 2014-02-21 08:22:30 <gmaxwell> But thats broken regardless of malleability.
549 2014-02-21 08:23:21 <maaku> it's like sending me cash in the mail, i tell you I didn't get it, so you send even more cash
550 2014-02-21 08:23:31 <maaku> that's broken regardless of what's going on at the post office
551 2014-02-21 08:23:35 <gmaxwell> (because you can have a case where it really hadn't gone through, and then both go through— say after the coins spent in the first one matures and some user pulls it from their api feed and rebroadcasts)
552 2014-02-21 08:24:07 <gmaxwell> Had they been sure to always double spend the original there would be no chance of both going through.
553 2014-02-21 08:24:07 <mrkent> gmaxwell, so if attacker was stealing from gox, they would need the mutated transactions to be on hold somehow for 12 hours to get paid twice?
554 2014-02-21 08:25:27 <mrkent> maaku, so you're saying gox sent out 2nd transaction after 12 hr, assuming the first one will be canceled and eventually come back to them?
555 2014-02-21 08:25:35 <gmaxwell> mrkent: somehow isn't a mystery: mtgox was spending immature coins— which couldn't be relayed or mined for up to 100 blocks— at least since august last year, they were also producing about 1% of their signatures with invalid DER encodings that bitcoin 0.8 won't relay or mine.
556 2014-02-21 08:26:20 <gmaxwell> presumably those issues are why they had the automatic reissuing process in the first place. I was unable to find anyone else that was performing automatic transaction reissuing.
557 2014-02-21 08:27:05 <mrkent> gmaxwell, what do u mean by "matures"
558 2014-02-21 08:28:49 <mrkent> gmaxwell, I see.. very interesting
559 2014-02-21 08:28:54 <mrkent> just parsed through all that
560 2014-02-21 08:29:40 <gmaxwell> mrkent: newly generated bitcoins are prohibited from being spent by the hardcoded, enforced by all nodes, innate rules of bitcoin.  MTGox's custom wallet software is apparently unaware of this. (still! they appear to this moment still producing transactions which spend immature coins). Newly generated coins must mature for 100 blocks before they can be spent.
561 2014-02-21 08:30:07 <gmaxwell> meaning that they produce transactions which all other bitcoin nodes will ignore for upto 100 more blocks, but then will relay and mine completely freely.
562 2014-02-21 08:30:32 <mrkent> So they claimed that they used some custom software rather than bitcoind. How much validity is there to that?
563 2014-02-21 08:30:37 <gmaxwell> Until/unless MTGox posts a list of theft transactions though the exact situations around this stuff will remain a mystery.
564 2014-02-21 08:31:38 <gmaxwell> mrkent: their wallet stuff is certantly not bitcoind. It behaves entirely unlike it, including things like invalid der encodings and the spending of immature coins. IIRC before MT took over MTGOX he was working on his own implementation, so it seems all sensible to me.
565 2014-02-21 08:31:42 <mrkent> gmaxwell, how does mtgox even have newly generated coins? Only miners have newly generated coins
566 2014-02-21 08:32:31 <mrkent> > relay and mine completely freely; by mine, u mean confirm?
567 2014-02-21 08:33:03 <gmaxwell> mrkent: because there are some pools like eligius and p2pool pay miners using freshly generated coins, and miners had put mtgox addresses in for their addresses.
568 2014-02-21 08:33:35 <gmaxwell> (a thing that was officially supported at mtgox too, AFAIK)
569 2014-02-21 08:34:04 <mrkent> gmaxwell, u mean the private key deposit method right?
570 2014-02-21 08:34:12 <gmaxwell> no.
571 2014-02-21 08:34:43 <lnovy> no the payment from mining is done by the coinbase transaction
572 2014-02-21 08:35:01 <lnovy> and some miners just put a mtgox's one there
573 2014-02-21 08:35:33 <mrkent> gmaxwell, how does the mining pool spend freshly generated coins?
574 2014-02-21 08:35:47 <lnovy> it does not... only way is the coinbase
575 2014-02-21 08:36:42 <gmaxwell> They either generate them directly to where they want them to go— or they wait 100 blocks.
576 2014-02-21 08:37:06 <mrkent> lnovy, what do u mean coinbase transaction?
577 2014-02-21 08:37:15 <lnovy> ou boy...
578 2014-02-21 08:37:33 <mrkent> i am assuming you don't mean the company
579 2014-02-21 08:37:36 <gmaxwell> mrkent: you're really asking bitcoin 101 stuff, this is better discussion for #bitcoin
580 2014-02-21 08:37:45 <lnovy> mrkent: this is a transaction that specifies where the fees and mining reward is "send"
581 2014-02-21 08:38:23 <mrkent> gmaxwell, I think your idea of 101 is a bit skewed as a developer
582 2014-02-21 08:38:28 <lnovy> mrkent: also read this after on how eligius is paying miners: http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay
583 2014-02-21 08:38:43 <gmaxwell> mrkent: This is a development channel, Mrkent.
584 2014-02-21 08:39:41 <mrkent> lnovy, I see. I sorta assumed that it was just sent to 1 address
585 2014-02-21 08:40:13 <gmaxwell> mrkent: https://en.bitcoin.it/wiki/Vocabulary in any case. And you really should move these questions to #bitcoin
586 2014-02-21 08:40:19 <lnovy> mrkent: that's just the basic type, there are many others types of transactions in bitcoin... dig into wiki
587 2014-02-21 08:40:27 <mrkent> So the freshly generated coin is automatically deposited into pool contributors accounts, some of which is mtgox address
588 2014-02-21 08:40:36 <lnovy> 
ACTION mutes

589 2014-02-21 08:41:52 <mrkent> gmaxwell, sure
590 2014-02-21 08:43:40 <lnovy> gmaxwell: not sure if this wasn't the same before... but... https://data.mtgox.com/api/1/generic/bitcoin/block_list_tx?depth=188112
591 2014-02-21 08:44:12 <lnovy> i've tried couple of blocks, complete clusterfuck
592 2014-02-21 08:52:21 <Persopolis> gents could you point me to any docs that defines what the minimal reqs are for interfacing with p2p network that still allows block data queries - i.e. lightweight version of bitcoind
593 2014-02-21 08:55:20 <wumpus> Persopolis: I suppose the goal is to query without being queried, so it'd make sense to use the same approach as existing SPV clients
594 2014-02-21 08:56:11 <lnovy> Persopolis: try look at the some projects like BitcoinKit.framework
595 2014-02-21 08:56:25 <lnovy> or there was something "new" recently, i cannot remember
596 2014-02-21 08:56:46 <Persopolis> spv looks good wumpus - ty
597 2014-02-21 09:01:04 <wumpus> maaku: I suppose your per-data-item error correction method can be useful when representing seeds for deterministic wallets;  in this case there is only one item to encode/decode
598 2014-02-21 09:30:13 <Persopolis> picocoin seems to have good chunk of what i need :) thanks for the help guys
599 2014-02-21 10:08:35 <wallet42> http://coinlogic.wordpress.com/2014/02/18/the-protocol-1-block/ aww colors! :)
600 2014-02-21 10:29:28 <buhbuh> ;; market sell 10000
601 2014-02-21 10:29:29 <gribble> Bitstamp | A market order to sell 10000 bitcoins right now would net 5107993.8231 USD and would take the last price down to 462.0000 USD, resulting in an average price of 510.7994 USD/BTC. | Data vintage: 0.0219 seconds
602 2014-02-21 10:29:57 <SomeoneWeird> are there any public peers?
603 2014-02-21 10:49:10 <Mallstromm> ;;market sell 40000
604 2014-02-21 10:49:11 <gribble> Bitstamp | A market order to sell 40000 bitcoins right now would net 13178919.4229 USD and would take the last price down to 100.0000 USD, resulting in an average price of 329.4730 USD/BTC. | Data vintage: 0.0548 seconds
605 2014-02-21 10:49:30 <Mallstromm> :D
606 2014-02-21 10:50:48 <buhbuh> :)
607 2014-02-21 10:55:00 <gribble> test
608 2014-02-21 10:55:47 <lmatteis> guys
609 2014-02-21 10:56:14 <lmatteis> where do i find info on which chain is accepted by nodes? is it the longest (as in amounts of blocks), or the chain with most work put into it?
610 2014-02-21 10:58:04 <stonecoldpat> longest
611 2014-02-21 10:58:11 <stonecoldpat> as longest = most work put into it
612 2014-02-21 11:01:07 <maaku> buhbuh: do it.
613 2014-02-21 11:01:41 <maaku> lmatteis: most work
614 2014-02-21 11:01:55 <maaku> *most work and valid
615 2014-02-21 11:05:02 <wumpus> yes the one where the sum of GetBlockWork() is largest ( https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L805 ) is regarded as main chain
616 2014-02-21 11:07:42 <stonecoldpat> (this is because its provable that most work has gone into the longest chain - as you have got some results, if nodes were working longer on a single block, there is no evidence about the amount of work they haev actually done)
617 2014-02-21 11:08:00 <chairman_meow> hello
618 2014-02-21 11:08:10 <ZjP> not the longest, but the one with highest difficulty adjusted length
619 2014-02-21 11:09:34 <stonecoldpat> ZjP: it would be the longest, as nodes dont expect the most difficult block, but one that meets a certain threshold, in other words, 'the longest chain of blocks that meet the expected difficulty' - as solving anymore more difficult than required is wasted effort
620 2014-02-21 11:10:50 <wumpus> but you could by accident find a block that is more difficult than necessary?
621 2014-02-21 11:11:33 <wumpus> okay unlikely...
622 2014-02-21 11:11:57 <stonecoldpat> you could i guess, if its 1(a) vs 1(b) block, and b is more difficult... i guess b would be expected ?
623 2014-02-21 11:12:10 <stonecoldpat> im not sure if the most difficult in that chance is expected, or just the one heard first
624 2014-02-21 11:12:35 <stonecoldpat> i remember some discussion about it when the self-miner attack was proposed, but memory is a bit hazy