1 2014-03-25 00:05:37 <sipa> maaku: hmm, a ban score for non-standard tx? that sounds wrong
  2 2014-03-25 00:07:26 <phantomcircuit> sipa, iirc there's a ban score of 0 for that
  3 2014-03-25 00:08:53 <sipa> if it's nonzero, we risk temporarily splitting the network with a new version that changes standardness
  4 2014-03-25 00:09:28 <phantomcircuit> sipa, yeah i know
  5 2014-03-25 00:09:36 <phantomcircuit> im *pretty* sure it's zero
  6 2014-03-25 00:09:46 <phantomcircuit> gavinandresen, i think you would know?
  7 2014-03-25 00:11:29 <sipa> how about we just check the code instead of wasting time discussing it
  8 2014-03-25 00:11:58 <sipa> score is 0
  9 2014-03-25 00:12:33 <maaku> sipa: it is zero
 10 2014-03-25 00:12:50 <maaku> but why is it using DoS(0, ...) instead of error()?
 11 2014-03-25 00:13:02 <maaku> that was my question
 12 2014-03-25 00:13:05 <sipa> oh
 13 2014-03-25 00:13:11 <sipa> error just returns false
 14 2014-03-25 00:13:21 <sipa> you need to mark the CValidationState object as invalid
 15 2014-03-25 00:13:28 <sipa> but state.Invalid would do that too
 16 2014-03-25 00:15:02 <maaku> which just calls DoS(0, ...); ok, I see
 17 2014-03-25 00:15:34 <sipa> maybe .Invalid doesn't implement all parameters that DoS does?
 18 2014-03-25 02:22:15 <amstertran> why are the txid's reversed in the hex encoding?
 19 2014-03-25 02:23:29 <sipa> because someone, at some point, chose that encoding
 20 2014-03-25 02:23:51 <sipa> the confusion comes from the fact that in some places, it is interpreted as a number, and in others as a byte sequence
 21 2014-03-25 02:24:16 <sipa> interpreting it as a number and printing that out in hex results in the opposite order as printing the individual bytes in hex
 22 2014-03-25 02:24:35 <Apocalyptic> in little-endian systems
 23 2014-03-25 02:24:46 <maaku> "Because I said so." -Satoshi
 24 2014-03-25 02:24:54 <amstertran> lol
 25 2014-03-25 02:25:08 <sipa> Apocalyptic: bitcoin always uses little-endian for numbers
 26 2014-03-25 02:25:44 <sipa> amstertran: ultimately, "we don't know; ask Satoshi"
 27 2014-03-25 02:25:46 <Apocalyptic> indeed, was just precising your statement
 28 2014-03-25 02:25:49 <Adlai> how's the interest/support for a port of the core bitcoin client to a new platform/language /
 29 2014-03-25 02:25:52 <Adlai> ?
 30 2014-03-25 02:26:08 <sipa> Adlai: platform sure; language hell no
 31 2014-03-25 02:26:35 <Adlai> sipa: why not? doesn't a multitude of conforming implementations indicate a strong specification?
 32 2014-03-25 02:26:56 <sipa> Adlai: consensus mechanisms such a bitcoin are very special in that regard
 33 2014-03-25 02:27:09 <sipa> Adlai: put simply, consistency is more important than correctness
 34 2014-03-25 02:27:33 <Apocalyptic> sipa, very well said
 35 2014-03-25 02:27:44 <sipa> Adlai: nodes in the network must all, independently, come to the same conclusion about which transactions and blocks are valid and which aren't
 36 2014-03-25 02:28:01 <sipa> Adlai: and, unfortunately, that means replicating the behaviour of existing nodes in the network bug-for-bug
 37 2014-03-25 02:28:12 <sipa> (at least the consensus rules; not necessarily implemented policies)
 38 2014-03-25 02:28:22 <Adlai> by "language" I just mean the language used to write the client... if it wouldn't behave the same as the reference implementation, that'd be a bug and I'd have to fix it.
 39 2014-03-25 02:28:31 <sipa> Adlai: yes, indeed
 40 2014-03-25 02:28:53 <Adlai> 
ACTION is thinking of common lisp... fuck him, right!?

 41 2014-03-25 02:28:59 <sipa> Adlai: but i don't believe current engineering state of the art is able to replicate the behaviour of something as complex as bitcoin without making mistakes
 42 2014-03-25 02:29:18 <sipa> Adlai: hell, it isn't so long ago that we ourselves found behaviour in the client that was unexpected
 43 2014-03-25 02:29:21 <maaku> Adlai: I'm only wondering why you chose CL out of all the wonderful other lisps :P
 44 2014-03-25 02:29:38 <Adlai> maaku: I'd love to take you up on that, but in PM since this is -dev after all :)
 45 2014-03-25 02:30:35 <sipa> Adlai: that's not to say there can't be other clients of course, but imho trying to reimplement the consensus rules is a bad idea
 46 2014-03-25 02:31:32 <Adlai> 
ACTION will do it as an intellectual exercise, then

 47 2014-03-25 02:31:58 <Adlai> given sufficient free time, of course. not all of us get paid to hack on bitcoin... ;_;
 48 2014-03-25 02:32:05 <sipa> very few do
 49 2014-03-25 02:32:20 <Adlai> the lucky few :)
 50 2014-03-25 02:32:38 <Adlai> not to imply that talent had nothing to do with it
 51 2014-03-25 02:32:46 <sipa> only wumpus and gavin, actually
 52 2014-03-25 02:32:53 <sipa> (speaking about the reference client, that is)
 53 2014-03-25 02:33:09 <venzen> sipa: what about bitcoinj then? isn't that a diff lang implementation?
 54 2014-03-25 02:33:27 <sipa> venzen: it doesn't implement the consensus rules
 55 2014-03-25 02:33:32 <venzen> ah
 56 2014-03-25 02:33:53 <sipa> well, it has an experimental mode which does, but it is not encouraged, and the developers are talking about deleting it
 57 2014-03-25 02:36:37 <venzen> thanks, sipa
 58 2014-03-25 02:37:55 <dgenr8> BlueMatt: or anyone, is this my fault? http://jenkins.bluematt.me/pull-tester/43d6ff23a23b87fa44a92242a61b9bb3a9c4eb1e/
 59 2014-03-25 02:38:15 <sipa> dgenr8: no
 60 2014-03-25 02:38:26 <sipa> current git head has broken tests
 61 2014-03-25 02:38:38 <dgenr8> phew, thanks
 62 2014-03-25 02:47:16 <Adlai> sipa: so would the main concern in this regard be implementing the exact same consensus rules as the reference client?
 63 2014-03-25 02:47:33 <Adlai> (this is something that can be "trivially" tested for)
 64 2014-03-25 02:47:40 <Adlai> with huge scare quotes, of course
 65 2014-03-25 02:52:03 <shadders> I worked out why bitcoind is returning blocks with all 0s.  My blk00000.dat is missing.  Apparently rather than failing it just reads an array of 0s.  Client still works fine but I imagine if a tx ever appears that relies on an output contained in that file things will go downhill pretty fast.
 66 2014-03-25 02:53:46 <shadders> The other odd bit is that blk00001.dat is 229mb whereas every other blkxxxxx.dat file is the standard 134mb
 67 2014-03-25 02:59:09 <sipa> shadders: that's very interesting; can you file a bug?
 68 2014-03-25 02:59:22 <sipa> shadders: it should fail instead of returning zeroes...
 69 2014-03-25 02:59:46 <sipa> Adlai: trivially? :o
 70 2014-03-25 03:01:10 <sipa> Adlai: we already have a test system which generates blocks on the fly to test out various scenarios of weird edge cases that were discovered over time
 71 2014-03-25 03:02:53 <shadders> sipa: is the issue tracker on github the right place?
 72 2014-03-25 03:03:20 <sipa> shadders: yes, github.com/bitcoin/bitcoin/issues
 73 2014-03-25 03:03:29 <shadders> will do
 74 2014-03-25 03:03:34 <sipa> thanks
 75 2014-03-25 03:03:57 <shadders> Been tearing my hair out trying to work this one out for 2 days.
 76 2014-03-25 03:04:25 <shadders> Just going to repeat on proper blockchain db to verify
 77 2014-03-25 03:14:34 <felipelalli> @sipa, please, where can I found the doc Official Policy of Bitcoin that Gaven mentioned here: https://github.com/bitcoin/bitcoin/pull/3944#issuecomment-38467282
 78 2014-03-25 03:14:41 <felipelalli> *Gavin I mean
 79 2014-03-25 03:15:58 <felipelalli> thank you in advance.
 80 2014-03-25 03:19:45 <Luke-Jr> felipelalli: I think he was just politely saying "we don't care what your companies did, this is how we decided to do it, and there's no room for debate"
 81 2014-03-25 03:20:06 <Luke-Jr> felipelalli: also, the companies are PROBABLY wrong. companies like to assert things that aren't true.
 82 2014-03-25 03:21:42 <felipelalli> But this Official Policy just does not exist? I want to study to avoid make mistakes like that in the future. In this specific case there is no "right" or "wrong". It just a convention. The right is follow the convention.
 83 2014-03-25 03:21:56 <felipelalli> Thanks @Luke-Jr
 84 2014-03-25 03:22:35 <Luke-Jr> felipelalli: I don't care to debate it, either.
 85 2014-03-25 03:23:03 <Luke-Jr> .. except to revise my previous statement: those companies are CERTAINLY wrong.
 86 2014-03-25 03:23:31 <felipelalli> I know the code conventions already (under /doc), but I would like to know if there is any "Official Policy".
 87 2014-03-25 03:23:46 <felipelalli> @Luke-Jr, yes, probably. You are right.
 88 2014-03-25 03:25:59 <felipelalli> Or the Official Policy is the Gavin decision? Understand that I'm not questioning anything, just want to learn. I tried to find all bitcoin-dev related docs, but I did not find any guide to conventions like that. If this just does not exist I totally understand. Thank you.
 89 2014-03-25 03:27:50 <Luke-Jr> there is no document
 90 2014-03-25 03:28:07 <felipelalli> Nice! Thank you @Luke-Jr.
 91 2014-03-25 03:32:06 <felipelalli> @Luke-Jr, if you would recommend me a job to do in Bitcoin Core, which kind of task is good for beginners? See that I am beginner on Bitcoin, not in development (14 years of experience). Thank you.
 92 2014-03-25 03:32:43 <Luke-Jr> felipelalli: unit tests, or a blockchain obfuscator
 93 2014-03-25 03:33:54 <Luke-Jr> blkchain obfuscator would just use a simple seed to scramble the block data files, so that someone can't mine spam that triggers virus detectors (or worse)
 94 2014-03-25 03:34:48 <felipelalli> Nice! Perfect! There are any issue open related with that?
 95 2014-03-25 03:34:54 <Luke-Jr> not sure
 96 2014-03-25 03:35:05 <Luke-Jr> felipelalli: or, even just reviewing open merge requests… the bottleneck is usually reviews ;)
 97 2014-03-25 03:35:06 <felipelalli> Ok, no problem, I'll try to find it.
 98 2014-03-25 03:35:31 <felipelalli> Also, it prevents desktop indexers to find ads inside blockchain.
 99 2014-03-25 03:36:00 <Adlai> sipa: link?
100 2014-03-25 03:36:07 <Luke-Jr> it prevents a variety of nastiness, anyway ;)
101 2014-03-25 03:36:15 <Adlai> (to the on-the-fly test block generator)
102 2014-03-25 03:36:26 <felipelalli> Yes, I did it once. But it's hard to me yet because I am unfamiliar with some parts of the code.
103 2014-03-25 03:36:46 <Luke-Jr> anyone have a testnet node I can add?
104 2014-03-25 03:37:29 <felipelalli> @Luke-Jr, all of you core developers are full time job dedicated to Bitcoin? This is just awesome. Congrats!
105 2014-03-25 03:37:45 <Luke-Jr> felipelalli: no, most aren't.
106 2014-03-25 03:37:52 <Luke-Jr> felipelalli: just 2 really
107 2014-03-25 03:37:59 <felipelalli> Really? So, more awesome yet!
108 2014-03-25 03:40:26 <Luke-Jr> 2 + 1 part time(?) + 1 try-to-break-bitcoin
109 2014-03-25 03:41:32 <phantomcircuit> Luke-Jr, i wonder who that last one could be
110 2014-03-25 03:41:59 <felipelalli> me too
111 2014-03-25 03:42:09 <phantomcircuit> that was a joke
112 2014-03-25 03:42:23 <Apocalyptic> is that hearn ?
113 2014-03-25 03:42:25 <felipelalli> magitux? :)
114 2014-03-25 03:43:36 <Luke-Jr> his name starts with a P
115 2014-03-25 03:43:59 <phantomcircuit> Luke-Jr, is it petertodd????
116 2014-03-25 03:44:07 <Luke-Jr> phantomcircuit: pfft, no need to name names!
117 2014-03-25 03:44:08 <Apocalyptic> Peter Wuille ?
118 2014-03-25 03:44:16 <felipelalli> I added Hearn just today to my PGP keychain
119 2014-03-25 03:44:40 <Luke-Jr> Apocalyptic: aww, what did sipa ever do to break bitcoin?
120 2014-03-25 03:45:21 <Apocalyptic> i'm not aware of anything, was just guessing
121 2014-03-25 03:45:41 <felipelalli> Luke-Jr, this guy break bitcoin just for to be unlucky or is he a troll?
122 2014-03-25 03:46:32 <Luke-Jr> felipelalli: I'm not sure he fits in either category.
123 2014-03-25 03:46:39 <phantomcircuit> oh ffs
124 2014-03-25 03:46:42 <phantomcircuit> it's not sipa
125 2014-03-25 03:46:46 <phantomcircuit> it's me you silly people
126 2014-03-25 03:49:14 <felipelalli> @Luke-Jr, let me ask one more thing advantage that you are happy today: I could note that Bitcoin uses few external libs (eg. LevelDB or an adapted python-json-rpc). The Bitcoin team in general prefer to make the things "at home" or is totally open to import external libs?
127 2014-03-25 03:50:46 <Luke-Jr> felipelalli: depends on cost/benefit
128 2014-03-25 03:51:36 <felipelalli> the cost would be for example maintain this external lib up to date and free of bugs?
129 2014-03-25 03:51:59 <Luke-Jr> eh, if it's not maintained, I don't see using it as a reasonable option
130 2014-03-25 03:52:22 <felipelalli> understood. thank you!
131 2014-03-25 03:53:11 <Luke-Jr> felipelalli: note GPL libraries are out of the question too, since we use OpenSSL
132 2014-03-25 03:53:51 <felipelalli> OpenSSL license?
133 2014-03-25 03:54:50 <felipelalli> I thought it was MIT
134 2014-03-25 03:55:22 <Luke-Jr> Bitcoin Core is MIT license, but we use the OpenSSL library
135 2014-03-25 03:55:26 <Luke-Jr> which is GPL-incompatible
136 2014-03-25 03:55:50 <felipelalli> Bitcoin should be BSD :)
137 2014-03-25 03:55:59 <Luke-Jr> same thing
138 2014-03-25 03:56:06 <felipelalli> very similar!
139 2014-03-25 03:59:04 <felipelalli> Luke-Jr, taking into advantage that you're VERY happy today, let me ask you just one more question (I swear now is the last one): how much open is the devs to code refactoring? Like split big files, improve possible duplicated codes, removing minor warnings etc? Or they prefer to "leave it as is and change as little as possible"?
140 2014-03-25 03:59:53 <Luke-Jr> felipelalli: change as little as possible, unless you have good reasons and good unit test coverage included
141 2014-03-25 04:00:17 <felipelalli> @Luke-Jr thank you!
142 2014-03-25 04:00:51 <felipelalli> I deduced that! thank you. good night!
143 2014-03-25 04:00:54 <Luke-Jr> we're desperately lacking unit tests :/
144 2014-03-25 04:01:22 <Apocalyptic> no wonder, it's so boring
145 2014-03-25 04:01:26 <felipelalli> when someone make some piece of new code, why this guy don't make also the unit test?
146 2014-03-25 04:01:53 <Luke-Jr> felipelalli: it's boring. though you'll have a hard time getting anything merged without unit tests now.
147 2014-03-25 04:02:01 <Luke-Jr> Satoshi had zero unit tests.
148 2014-03-25 04:02:50 <felipelalli> you are saying it's hard to make new untit tests without the basic ones?
149 2014-03-25 04:03:18 <Luke-Jr> no, I'm saying refactoring requires basic ones
150 2014-03-25 04:03:28 <Luke-Jr> to prove you didn't change any behaviour
151 2014-03-25 04:03:58 <felipelalli> hmmmmm!! understood.
152 2014-03-25 04:04:15 <felipelalli> without theses basic tests it's hard to make big refactorings. nice!
153 2014-03-25 04:04:36 <felipelalli> But the foundation already thought about to hire specialized companies to make unit tests? It's a monkey job, no one deverve it without be well paid.
154 2014-03-25 04:08:38 <felipelalli> Luke, which one is your actual PGP key? http://pgp.mit.edu/pks/lookup?op=get&search=0xBD02942421F4889F or http://pgp.mit.edu/pks/lookup?op=get&search=0x665FC11DD53E9583 ?
155 2014-03-25 04:09:50 <felipelalli> Forget it. I found it here: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/luke-jr-key.pgp
156 2014-03-25 04:10:50 <felipelalli> Luke-Jr, I'm sorry but this key is out of date.
157 2014-03-25 04:40:39 <Luke-Jr> felipelalli: what?
158 2014-03-25 04:45:46 <SomeoneWeird> ur out of date!!!!!!!
159 2014-03-25 04:59:07 <felipelalli> Luke-Jr, that link I sent to you, that pub key is expired.
160 2014-03-25 04:59:11 <felipelalli> You need to update that.
161 2014-03-25 04:59:27 <felipelalli> With the modified key with new expiriation.
162 2014-03-25 04:59:34 <felipelalli> This one: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/luke-jr-key.pgp
163 2014-03-25 04:59:36 <felipelalli> is expired.
164 2014-03-25 05:00:02 <lianj> got his new one, hold on… :D
165 2014-03-25 05:00:03 <Luke-Jr> felipelalli: I see. Not sure it matters, as long as it's the same key.
166 2014-03-25 05:27:14 <felipelalli> Luke-Jr, yes, it matters because when I import it my GPG client put you as gray  :)
167 2014-03-25 05:27:44 <Luke-Jr> so update it from a keyserver? :p
168 2014-03-25 05:28:27 <felipelalli> No, when I import from a key server no :) But the problem is that I was not sure that was you
169 2014-03-25 05:28:32 <felipelalli> I was sure only when I saw that it was the same key, but not obvious.
170 2014-03-25 05:28:49 <felipelalli> well... update in git if you want :) no problem!!
171 2014-03-25 05:29:24 <felipelalli> the problem is that you should make a pull request for that? haha
172 2014-03-25 05:29:29 <felipelalli> yes, so forget it... :/
173 2014-03-25 05:31:03 <felipelalli> if you want to update, put the link to a key server, so it will be always up to date
174 2014-03-25 07:04:41 <throughnothing> j #crowdtilt
175 2014-03-25 07:47:02 <shadders> how many blocks was each branch of the mar 2013 fork before it got resolved?
176 2014-03-25 07:53:57 <ribasushi> I am having trouble ./configure-ing bitcoin
177 2014-03-25 07:53:59 <ribasushi> http://paste.debian.net/89651/
178 2014-03-25 07:54:28 <ribasushi> there is nothing obvious in config.log, apart from the failed 4.8 dbd check, which ought to be masked by the further check for any version of dbd
179 2014-03-25 07:54:32 <ribasushi> thoughts?
180 2014-03-25 07:55:26 <gribble> https://en.bitcoin.it/wiki/BIP_0050
181 2014-03-25 07:55:26 <michagogo> cloud|shadders: see if the info is in ,,(lucky BIP 50)
182 2014-03-25 07:55:50 <michagogo> cloud|If not, maybe look at the IRC logs from then
183 2014-03-25 07:56:41 <Luke-Jr> ribasushi: boost filesystem
184 2014-03-25 07:56:59 <michagogo> cloud|ribasushi: looks like missing boost componet
185 2014-03-25 07:57:08 <michagogo> cloud|Oh, Luke-Jr already Sao dit
186 2014-03-25 07:57:12 <michagogo> cloud|Said it*
187 2014-03-25 07:57:37 <michagogo> cloud|ribasushi: did you install the boost-all-dev or whatever it's called mentioned in doc/build-unix?
188 2014-03-25 07:57:55 <shadders> It says what block it resolved.  Just not what time or block is started
189 2014-03-25 07:58:34 <ribasushi> yes, I have all that, and I can compile other daemons just fine (doge, dark, vert, aurora)
190 2014-03-25 07:58:43 <ribasushi> Luke-Jr: have it installed 1.54
191 2014-03-25 07:58:51 <ribasushi> let me get the full log pasted...
192 2014-03-25 08:00:29 <ribasushi> http://paste.debian.net/plain/89655
193 2014-03-25 08:00:34 <ribasushi> ^^ that's my full config.log
194 2014-03-25 08:01:18 <ribasushi> it's almost as if it completes and then exits 1 for no reason
195 2014-03-25 08:01:53 <michagogo> cloud|ribasushi: read the build-unix file
196 2014-03-25 08:02:06 <michagogo> cloud|Iirc there was something about 1.54 having a problem
197 2014-03-25 08:02:56 <ribasushi> well cocks.
198 2014-03-25 08:05:14 <venzen> ribasushi: what OS/distro are you on?
199 2014-03-25 08:05:49 <ribasushi> a sid-ish debian
200 2014-03-25 08:06:10 <venzen> hmm, what version libboost is default? 1.46?
201 2014-03-25 08:06:15 <michagogo> cloud|Does it not have 1.55?
202 2014-03-25 08:06:44 <ribasushi> it does, upgrading to that is tough, hence the cocks
203 2014-03-25 08:06:46 <ribasushi> working on it...
204 2014-03-25 08:06:53 <michagogo> cloud|What's hard?
205 2014-03-25 08:07:15 <michagogo> cloud|Is it more than `sudo apt-get update && sudo apt-get upgrade`?
206 2014-03-25 08:09:08 <ribasushi> when you maintain your pkg list by hand (yes I am one of those) - it's hard :)
207 2014-03-25 08:09:19 <ribasushi> anyway - "won't work on 1.54" is good enough of answer
208 2014-03-25 08:09:31 <ne0futur> <troll>when you need that you switch to gentoo or mageia</troll>
209 2014-03-25 08:10:41 <venzen> ribasushi: you may want to downgrade to 1.4x or compile from source (its not pretty...)
210 2014-03-25 08:11:51 <wumpus> I don't think it's a boost version issue at all, probably the build system does something wrong or detects a directory wrongly
211 2014-03-25 08:12:09 <wumpus> in principle bitcoin can compile with a wide range of boost versions
212 2014-03-25 08:12:32 <ribasushi> wumpus: it's "sweep under the rug" laziness
213 2014-03-25 08:12:48 <ribasushi> that is seeing the note in the readme
214 2014-03-25 08:13:07 <wumpus> ribasushi: yes it is, though debugigng autotools is painful, so it makes sense people try to avoid it :p
215 2014-03-25 08:13:39 <ribasushi> anyway 1.55 installed, trying...
216 2014-03-25 08:13:46 <wumpus> but if you're going through the trouble of compiling boost from source, man, why not just debug the build system and see why it fails with your boost and fix that...
217 2014-03-25 08:14:13 <ribasushi> wumpus: I am not compiling them from source thanks god ;)
218 2014-03-25 08:14:15 <ribasushi> also - same on 1.55
219 2014-03-25 08:14:24 <ribasushi> (absolutely same error)
220 2014-03-25 08:14:32 <wumpus> have you tried to manually provide the boost libdir and include dir?
221 2014-03-25 08:15:00 <ribasushi> wumpus: it "yes" -es every library it needs - look at the config: http://paste.debian.net/plain/89655
222 2014-03-25 08:15:00 <wumpus> (--with-boost-libdir= at least)
223 2014-03-25 08:15:11 <ribasushi> but let me try that too
224 2014-03-25 08:15:12 <wumpus> I don't care what it yes-es, it's pretty deceiving in that
225 2014-03-25 08:15:49 <wumpus> it can say 'yes' and then note the wrong path/value internally
226 2014-03-25 08:17:50 <wumpus> from what I remember it expects all the boost libraries in one directory, so if there is one false positive it expects all boost libs in that (wrong) directory
227 2014-03-25 08:38:48 <Jacques_> With multisig, it is a a P2SH address, which is the OPHASH160 of just the public keys and their signature of what? the transaction hash?
228 2014-03-25 08:39:43 <Jacques_> In P2SH, I don't see a CHECKSIG :/, only a hash comparison?
229 2014-03-25 08:40:12 <wumpus> hash of the input script IIRC
230 2014-03-25 08:41:26 <wumpus> and this input script contains the multisig signature checking
231 2014-03-25 08:42:45 <Jacques_> wumpus: so the input script must put something on the stack that when HASH160'd it must OP_EQUAL with the hash in the scriptPubKey
232 2014-03-25 08:43:39 <Jacques_> but how do you get that value to compare against first?
233 2014-03-25 08:43:44 <wumpus> see https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
234 2014-03-25 08:43:49 <Jacques_> I have, its a bit vague
235 2014-03-25 08:43:54 <Jacques_> (or I don't get it)
236 2014-03-25 08:45:15 <Jacques_> For example, it says "[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes.", but not what those 20 bytes are
237 2014-03-25 08:46:04 <wumpus> See step 2: Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
238 2014-03-25 08:46:07 <Jacques_> Its 20 bytes of the HASH160 of the scriptSig I assume
239 2014-03-25 08:46:49 <wumpus> it's the hash of {serialized script} which is the last thing pushed in the input script
240 2014-03-25 08:47:38 <wumpus> eh wait
241 2014-03-25 08:47:46 <wumpus> no I'm not sure actually...
242 2014-03-25 08:49:10 <Jacques_> that can't be the case, because that would mean you'd need the script originally to be signed by all
243 2014-03-25 08:49:25 <Jacques_> to which end you'd have to know where its going?
244 2014-03-25 08:49:35 <Jacques_> 2 transactions ahead?
245 2014-03-25 08:49:38 <Jacques_> *head explodes*
246 2014-03-25 08:49:58 <wumpus> yes that wouldn't make sense if you already need the fully-signed input
247 2014-03-25 08:50:29 <wumpus> but as I understand it, it's a script-in-a-script
248 2014-03-25 08:50:50 <wumpus> so it's not the input script itself that is hashed, but the serialized script that is pushed as part of the input script
249 2014-03-25 08:50:52 <sipa> yes, the last push of the input script is the serialozed redeemscript
250 2014-03-25 08:51:37 <sipa> and the data push in the output script is the hash160 of the serialized redeemscript
251 2014-03-25 08:53:55 <Jacques_> sipa: but where is the checkSig in all that?
252 2014-03-25 08:54:17 <Jacques_> sipa: otherwise someone could just take the redeemscript and spend without even bothering with the keys?
253 2014-03-25 08:55:00 <wumpus> you can't just take the redeemscript, it is also executed and needs to validate
254 2014-03-25 08:55:32 <Jacques_> wumpus: but you just said if you just take the hash160 and push that on the stack it would validate?
255 2014-03-25 08:56:01 <wumpus> that's only step two (there are three steps in that BIP)
256 2014-03-25 08:56:54 <Jacques_> an equivalent stepping process on the wikik (like what exists for pay to pub key) would be aesome
257 2014-03-25 08:56:58 <Jacques_> awesome*
258 2014-03-25 08:57:15 <wumpus> yes please add it :)
259 2014-03-25 08:58:55 <Jacques_> wumpus: if Only I understoood it haha
260 2014-03-25 09:06:47 <Jacques_> what does it mean serliaized script
261 2014-03-25 09:06:52 <Jacques_> This is already binary data?
262 2014-03-25 09:09:18 <wumpus> it means the script in binary form as it is normally read
263 2014-03-25 09:11:32 <sipa> Jacques_: the checksig is inside the redeemscript
264 2014-03-25 09:14:19 <Jacques_> sipa: if only I could just find some examples :S, currently looking at the bitcoind tests, sort of helping lol, but they look completely different to what is in that bip16, mostly using CHECKMULTISIG
265 2014-03-25 09:14:57 <Jacques_> or is that redeemScript?
266 2014-03-25 09:15:10 <Jacques_> Which has to pass... to be able ot be hashed?
267 2014-03-25 09:15:34 <sipa> Jacques_: the redeemscript is the *actual* script, which imposes the conditions under which the output can be spent
268 2014-03-25 09:15:52 <sipa> Jacques_: in normal transactions, we put that in the output directly
269 2014-03-25 09:15:58 <Jacques_> sipa: you mean the scriptSig right?
270 2014-03-25 09:16:09 <Jacques_> not scriptPubKey
271 2014-03-25 09:16:14 <sipa> Jacques_: no, the scriptPubKey (in normal transactions)
272 2014-03-25 09:16:41 <sipa> not talking about p2sh at all for now
273 2014-03-25 09:17:31 <sipa> in normal transactions, outputs contain a script that defines the conditions under which the output can be spent, and inputs spending them contain the data needed to make those scripts evaluate to true
274 2014-03-25 09:18:08 <sipa> so, output contaims a pubkey and a checksig, input contaims a signature
275 2014-03-25 09:18:11 <sipa> for example
276 2014-03-25 09:18:14 <sipa> ok?
277 2014-03-25 09:19:30 <Jacques_> I understand normal tx's, scriptSig : <sig> <pubKey>   etc, that makse sense, its that you're putting the redeemable conditions in the inputscript instead of the outputscript that is making it weird
278 2014-03-25 09:20:35 <wumpus> it only makes sense because the output specifies the hash of those conditions, which prevents messing with them
279 2014-03-25 09:21:22 <Jacques_> wumpus: right, so now I just want to know how serializedtx gets pushed on the stack, and that doesn't seem exactly clear, at least not that I can see atm
280 2014-03-25 09:21:39 <Jacques_> uh, serializedsig*
281 2014-03-25 09:21:58 <sipa> Jacques_: say you want to make a p2sh that simply does check for a sig with a given public key
282 2014-03-25 09:22:27 <sipa> Jacques_: the redeemscript is: [pubkey] OP_CHECKSIG
283 2014-03-25 09:23:16 <sipa> the input script becomes: [signature] [[pubkey] OP_CHECKSIG]
284 2014-03-25 09:23:54 <Jacques_> sipa: what do the brackets represent?
285 2014-03-25 09:24:13 <sipa> Jacques_: data push
286 2014-03-25 09:24:29 <sipa> so an opcode that pushes some byte array on the stack
287 2014-03-25 09:24:58 <Jacques_> so how does the redeemscript ever evaluate if its on the stack? :S
288 2014-03-25 09:25:08 <sipa> it's a rule
289 2014-03-25 09:25:15 <sipa> added by bip16
290 2014-03-25 09:25:40 <sipa> that if the output scriopt has a special form, the last stack element gets interpreted as a script again and evaluated too
291 2014-03-25 09:26:51 <Jacques_> sipa: that seems very special cased... lol
292 2014-03-25 09:27:09 <sipa> that form is: OP_HASH160 [hash([pubkey] OP_CHECKSIG)] OP_EQuAL
293 2014-03-25 09:27:11 <sipa> it is
294 2014-03-25 09:27:54 <sipa> but it allows moving the conditions for spending from the output to the inpuit
295 2014-03-25 09:28:21 <sipa> so the sender doesn't need to know what the receiver is going to do with it
296 2014-03-25 09:28:28 <sipa> and doesn't need to care
297 2014-03-25 09:28:55 <Jacques_> sipa: yet the sender doesn't care what the receiver does in a standard tx
298 2014-03-25 09:29:14 <sipa> Jacques_: agree, but he does need to know it
299 2014-03-25 09:29:27 <Jacques_> so that seems like a non-point, this more seems oriented around the fact that script is a stackbased language?
300 2014-03-25 09:29:59 <sipa> also, and perhaps more importantly, it means the (potemtially large) redeemscript doesn't need to be in the chainstate database
301 2014-03-25 09:30:01 <Jacques_> (thanks for the help btw)
302 2014-03-25 09:30:16 <sipa> only its hash does
303 2014-03-25 09:30:29 <Jacques_> but it still gets in there on the next tx?
304 2014-03-25 09:30:35 <sipa> no
305 2014-03-25 09:30:52 <sipa> the chainstate only contaims unspent transaction outputs
306 2014-03-25 09:31:36 <Jacques_> unsure of what u mean by chainstate, will look that up
307 2014-03-25 09:31:43 <Jacques_> (thought u meant blockchain)
308 2014-03-25 09:31:46 <sipa> no
309 2014-03-25 09:31:56 <sipa> the database of all unspent transaction outputs
310 2014-03-25 09:32:07 <sipa> at a particular point in the chain
311 2014-03-25 09:32:45 <Jacques_> right
312 2014-03-25 09:32:46 <sipa> anoither reason: p2sh means the receiver becomes responsible for the fees related to putting his (potemtially large) redeemscript in the chain
313 2014-03-25 09:32:54 <Jacques_> got it
314 2014-03-25 09:32:54 <Jacques_> its the leveldb
315 2014-03-25 09:33:10 <sipa> the current implementation uses leveldb for the chainstate yes
316 2014-03-25 09:33:42 <sipa> 0.7 amd before didn't have an explicit chainstate, only an imdex of which transaction was spent where (In bdb)
317 2014-03-25 09:34:59 <sipa> if we could design bitcoin today it wouls very likely be just p2sh only, without the hacks that were needed to make it (moderately) safe to roll out
318 2014-03-25 09:36:02 <wumpus> yes the way it is done now is just a clever way to fit it into the current system, which may seem contorted at first glance
319 2014-03-25 09:37:15 <Jacques_> interesting
320 2014-03-25 09:37:16 <sipa> btw, the chainstate database implementation also has a special case for p2sh, and it just stores the redeemscript hash, not the script around it
321 2014-03-25 09:37:30 <Jacques_> why is there a PUSHDATA4, considering the max isl ike 520 bytes? haha
322 2014-03-25 09:37:31 <sipa> so there is no real cost to it there
323 2014-03-25 09:37:42 <sipa> Jacques_: pushdata4 predayes the size limit
324 2014-03-25 09:37:48 <sipa> *predates
325 2014-03-25 09:38:09 <sipa> bip62 will basically remove pushdata4
326 2014-03-25 09:38:41 <Jacques_> nice! also, why not just use the VarInt instead of 4 different opcodes? (0-76, OP_PUSHDATA1,2,4)
327 2014-03-25 09:38:50 <Jacques_> (uh, 1-76**)
328 2014-03-25 09:38:57 <wumpus> Jacques_: there's so many 'why?' about the script system, don't even bother :)
329 2014-03-25 09:39:20 <sipa> Jacques_: the varint push only goes up to 76 bytes
330 2014-03-25 09:39:42 <Jacques_> disregard that, I completely ignored the other opcodes > 80 lol...
331 2014-03-25 09:40:01 <sipa> but indeed, the real answer is "go ask satoshi"
332 2014-03-25 09:40:03 <wumpus> it's like this because satoshi created it this way and changing would be very expensive
333 2014-03-25 09:40:06 <Jacques_> but yeah, wumpus, leran to love.
334 2014-03-25 09:40:21 <Jacques_> learn*** this damn terminal is so slow for input keeps getting out of sync lol
335 2014-03-25 09:40:25 <wumpus> at some point in the future, when the requirements are perfectly clear, a hardfork with script redesign may make sense
336 2014-03-25 09:41:10 <Jacques_> wumpus: requirements? clear? ha
337 2014-03-25 09:41:31 <sipa> script 2.0, p2sh only, with merkleized asts, schnorr signatures, guaranteed nonmalleability, ...
338 2014-03-25 09:41:44 <Jacques_> sipa: can only hope
339 2014-03-25 09:43:18 <Jacques_> sipa: just reading BIP62
340 2014-03-25 09:43:30 <Jacques_> now half the malleability problems make a bit more sense lol
341 2014-03-25 09:43:53 <wumpus> Jacques_: well I mean when the area of 'what is likely to be done in transactions' has been explored a bit, so that it's neither over- nor under designed
342 2014-03-25 09:44:30 <wumpus> trying to design a new format now is like trying to design an architecture for the internet in 2010, in 1995
343 2014-03-25 09:44:55 <sipa> <marquee> ...
344 2014-03-25 09:46:18 <wumpus> hehe, yes it would likely have involved a new animated gif format, marquees with extra special physics effects, a blink tag that fades in and out, an <underconstruction> tag etc:p
345 2014-03-25 09:47:41 <Jacques_> wumpus: as long as <drm> doesn't appear :P
346 2014-03-25 09:48:23 <sipa> <web2.0>
347 2014-03-25 09:48:36 <wumpus> Jacques_: ofcourse, OP_DRM will be an integral part of script 2.0, I do want people to pay license fees for using my transaction scripts!
348 2014-03-25 09:50:32 <midnightmagic> 
ACTION shudders at the horrible clamour that will ensue if such a hardfork is ever considered publically

349 2014-03-25 09:51:01 <Jacques_> midnightmagic: only way to prevent such a calamity will be to ensure multiple clients
350 2014-03-25 09:51:21 <sipa> a new script CAN be deployed with just a softfork :p
351 2014-03-25 09:51:25 <sipa> Jacques_: huh?
352 2014-03-25 09:51:37 <midnightmagic> multiple clients is probably good. multiple mining clients will open the gate to nyarlathotep
353 2014-03-25 09:51:40 <midnightmagic> :)
354 2014-03-25 09:52:08 <Jacques_> sipa: imho, only 1 reference client is just another oppurtunity for an authority to dictate what the majority do
355 2014-03-25 09:52:32 <sipa> Jacques_: you can fork it, or choose not to run a new versiom
356 2014-03-25 09:52:34 <wumpus> Jacques_: no one dictates anything, it's open source your know
357 2014-03-25 09:52:37 <wumpus> -r
358 2014-03-25 09:53:03 <Jacques_> of course, but, lets assume that happened today
359 2014-03-25 09:53:12 <Jacques_> if suddenly 100 bitcoin forks popped up
360 2014-03-25 09:53:14 <wumpus> there is not 'one reference client' anyway, many people are running their own variants
361 2014-03-25 09:53:27 <midnightmagic> <-- is running his own (very minor) variant
362 2014-03-25 09:53:29 <Jacques_> which one do the majority look to for 'reference'
363 2014-03-25 09:53:31 <sipa> Jacques_: a hard fork requires _everyone_ to update their client (not just miners, and not just 51%), so if it's the slightest bit controversial, it just can't be done
364 2014-03-25 09:53:38 <Jacques_> sipa: you're missing my point
365 2014-03-25 09:53:49 <sipa> Jacques_: for a hardfork, "majority" doesn't matter
366 2014-03-25 09:53:58 <sipa> everyone needs to run the same code
367 2014-03-25 09:54:14 <sipa> intentionally forking is suicide for bitcoin
368 2014-03-25 09:54:24 <Jacques_> sipa: hmmm, what I mean is, lets say 90% of the world are abiding by what is set out as the protocol in bitcoind
369 2014-03-25 09:54:49 <Jacques_> something controversial appears, from some shady pricks on the bitcoind dev team (NSA NSA NSA NSA ... jk anyway)
370 2014-03-25 09:54:53 <wumpus> but indeed, in case of a hardfork *everyone* has to agree
371 2014-03-25 09:54:58 <sipa> Jacques_: depends who that 10% is
372 2014-03-25 09:55:20 <wumpus> if it is the slightly bit controversial it cannot happen
373 2014-03-25 09:55:23 <Jacques_> suddenly, you can either hard fork by staying on the previous client, and get a new dev team together etc
374 2014-03-25 09:55:29 <sipa> Jacques_: if a few developers or importamt businesses say loudly they refuse to update, what do you think will happen?
375 2014-03-25 09:55:32 <Jacques_> or, you can follow the new rules
376 2014-03-25 09:56:08 <sipa> i think it's importsnt to distinguish client developers from consensus rule changes
377 2014-03-25 09:56:14 <Jacques_> if its something goverment/regulation related, you can bet the split won't be so obvious
378 2014-03-25 09:56:17 <wumpus> +1 sipa
379 2014-03-25 09:56:25 <Jacques_> sipa: agreed
380 2014-03-25 09:56:29 <wumpus> which is why we should pack the consensus part into a seperate library as soon as possible
381 2014-03-25 09:56:35 <sipa> there has only once ever be an incompatible consensus rule change
382 2014-03-25 09:56:48 <sipa> and that was an pbvious and totally uncontroversial bugfix
383 2014-03-25 09:56:55 <wumpus> and mark it with *changes to this are forbidden*
384 2014-03-25 09:57:27 <sipa> *been
385 2014-03-25 09:57:29 <anton000> correct me if im wrong, but hard forks will ultimately be decided by the economic majority?
386 2014-03-25 09:57:38 <Jacques_> anton000: by the mining majority I guess
387 2014-03-25 09:57:59 <sipa> Jacques_: No No NOOO
388 2014-03-25 09:58:13 <sipa> Jacques_: hard forks require everyone to update
389 2014-03-25 09:58:15 <Jacques_> sipa: supported by the mining majority*, decided by the node majoirity*
390 2014-03-25 09:58:32 <epscy> depends how centralized the mining majority is
391 2014-03-25 09:58:41 <sipa> they just need support from *everyone* running full nodes
392 2014-03-25 09:58:53 <epscy> i find it difficult to imagine that if 100% of miners wanted a change it wouldn't happen
393 2014-03-25 09:59:28 <wumpus> if that means 99% of the miners is mining with invalid rules not accepted by the rest of the network, they effectively don't eist
394 2014-03-25 09:59:31 <anton000> even if minining majoprity doesnt follow a for.... they ill eventually if the money goes to the fork. i.e. all exchanges follow ne fork
395 2014-03-25 09:59:35 <sipa> Jacques_: if miners were to decide today to raise their subsidy to 100 BTC, and start runningf a patched version to do so, all of them, what will happen?
396 2014-03-25 09:59:39 <wumpus> it would be like mining on a side chain no one cares about
397 2014-03-25 09:59:41 <epscy> non miners would be left on a fork that doesn't find any blocks, at that point they either accept the change or invest heavily in mining hardware
398 2014-03-25 09:59:44 <anton000> even if minining majoprity doesnt follow a forl.... they will eventually if the money goes to the fork. i.e. all exchanges follow ne fork
399 2014-03-25 09:59:58 <wumpus> epscy: that's also like 'what if everyone in the world was to jump at once'
400 2014-03-25 10:00:07 <sipa> epscy: it would be trivial to mine that chain :)
401 2014-03-25 10:00:08 <Jacques_> sipa: people that only want 99BTC would dominate right? :P
402 2014-03-25 10:00:29 <epscy> sipa: sipa well depends on the difficulty no?
403 2014-03-25 10:00:31 <sipa> Jacques_: subsidy is 25 now
404 2014-03-25 10:00:46 <Jacques_> ah, u meant reward, not fee
405 2014-03-25 10:00:48 <midnightmagic> lol and they'd all be mining on their own little minority-node fork while everyone waited for them to come to their senses..  or a minority of the miners would wake up and realise it makes them more money to mine on the fork that everyone who *uses* it is using.
406 2014-03-25 10:01:01 <sipa> Jacques_: subsidy yes :)
407 2014-03-25 10:01:16 <Jacques_> then, they'd hardfork right
408 2014-03-25 10:01:21 <Jacques_> and no one would follow them?
409 2014-03-25 10:01:32 <Jacques_> the blocks would just reject
410 2014-03-25 10:01:35 <epscy> midnightmagic: we hope, this is really the social, psychological game theory aspect of the bitcoin protocol
411 2014-03-25 10:01:35 <Jacques_> for the majority
412 2014-03-25 10:02:05 <sipa> Jacques_: indeed, everyone would just ignore them
413 2014-03-25 10:02:51 <anton000> so in the end, its consensus by the economic majority
414 2014-03-25 10:03:05 <Jacques_> the node majority* ?
415 2014-03-25 10:03:12 <sipa> Jacques_: no
416 2014-03-25 10:03:37 <Jacques_> how can someone not running a node have consensus?
417 2014-03-25 10:03:44 <midnightmagic> in the contrived example, the number of people following them would be 0 because that is the definition of the conundrum. In reality, I highly doubt a miner would risk destabilization by attempting to push a rule change through that gave them more money. Besides, it turns out nearly all miners are morons anyway.
418 2014-03-25 10:03:44 <sipa> Jacques_: economic majority means "important players decide"
419 2014-03-25 10:04:04 <sipa> Jacques_: because this is consensus at the human level, not technical
420 2014-03-25 10:04:25 <sipa> imagine two parties were to arise, some want a protocol change, some don't
421 2014-03-25 10:04:42 <sipa> and they are both completely unwilling tomchange their position
422 2014-03-25 10:04:53 <sipa> it meams the network will inevitably fork
423 2014-03-25 10:04:58 <anton000> i.e. if facebook, google, microsoft, twitter, decided to abandon icann and create thier own dns system because icann is being evil it ill happen.
424 2014-03-25 10:05:23 <midnightmagic> 
ACTION prepares to maintain bitcoins on multiple forks and wait for one to wither and die.

425 2014-03-25 10:07:58 <epscy> i'm just not sure we can rely on people to rational in that situation (particularly if mining is highly centralized)
426 2014-03-25 10:08:08 <epscy> but i guess this is OT
427 2014-03-25 10:08:13 <anton000> lol
428 2014-03-25 10:08:32 <sipa> people... rational?
429 2014-03-25 10:08:41 <sipa> in bitcoin?
430 2014-03-25 10:08:44 <midnightmagic> miners... people?
431 2014-03-25 10:09:08 <midnightmagic> mm..  okay..  bit harsh there. sorry.
432 2014-03-25 10:09:46 <ribasushi> epscy: anton's is a reasonable question, I am not sure why you are dismissing it (or it seems you do). Say eligius and ghash decide to alter the rules, and announce to all their miners "upgrade to bfgcoin 1.0 because X and Y, and OH 50btc for another year"
433 2014-03-25 10:10:26 <anton000> ribasushi...  , it doesn nothing if exchanges decided they ont follow that fork
434 2014-03-25 10:10:42 <ribasushi> how can they afford not to? (plus ghash *is* an exchange)
435 2014-03-25 10:10:47 <anton000> becase that 50btc will no be equal to 0 economic value
436 2014-03-25 10:10:55 <epscy> ribasushi: i don't know what would happen in that situation, if i had to guess I would say the eligius/ghash fork would lose out eventually
437 2014-03-25 10:11:01 <anton000> ghash is a huge economic vote
438 2014-03-25 10:11:13 <anton000> exactly what is meant by economic majority
439 2014-03-25 10:11:20 <anton000> exchange + mining power
440 2014-03-25 10:11:22 <epscy> ribasushi: but up the numbers to 90% or 100% of all miners, then what happens?
441 2014-03-25 10:11:27 <ribasushi> epscy: what makes you think the fork will lose? (not trolling, real question)
442 2014-03-25 10:12:03 <epscy> ribasushi: i don't know the numbers but i am guessing eligius/ghash is not much more than 50% of total hashpower
443 2014-03-25 10:12:13 <wumpus> no fork will 'lose', how do you define that anyway? the point is that they will both exist
444 2014-03-25 10:12:23 <epscy> ribasushi: in which case they wouldn't be able to force a consensus and would eventually give up
445 2014-03-25 10:12:26 <sipa> for a hardfork, mining power doesn't matter
446 2014-03-25 10:12:27 <wumpus> there will be basically two altcoins, bitcoin1 and bitcoin2
447 2014-03-25 10:12:32 <sipa> not even if it is 100%
448 2014-03-25 10:12:46 <anton000> yup
449 2014-03-25 10:12:46 <epscy> wumpus: i define lose as capitulate and switch to the other fork
450 2014-03-25 10:12:46 <ribasushi> sipa: ok, throw in the fish ;) https://blockchain.info/pools
451 2014-03-25 10:12:52 <epscy> sipa: why?
452 2014-03-25 10:12:59 <sipa> they are economic actors in the game, amd play their part
453 2014-03-25 10:13:09 <sipa> but they are not privileged
454 2014-03-25 10:13:14 <anton000> yes
455 2014-03-25 10:13:16 <epscy> sipa: if there are no miners on a fork, there are no blocks, this seems like a huge problem to me
456 2014-03-25 10:13:19 <midnightmagic> Nobody would switch because some greedy miner wanted to pay themselves a higher subsidy. The value is based on consensus of value. The notion of value is itself the reason why value persists. Thus it would be a meaningless alteration anyway. Since it's pointless and hollow, and since even if it weren't it would be unfair, nobody would go with them. Also, mining != economic power in bitcoin.
457 2014-03-25 10:13:37 <ribasushi> sipa: but they can offer a *clear and tangible* incentive to folks to change their clients en-masse
458 2014-03-25 10:13:41 <wumpus> epscy: you mean, just like litecoin capitulates to bitcoin? :p
459 2014-03-25 10:13:43 <Jacques_> epscy: until the difficulty drops
460 2014-03-25 10:13:50 <sipa> ribasushi: i don't see how
461 2014-03-25 10:13:51 <Jacques_> and other miners get in
462 2014-03-25 10:14:05 <anton000> epscy, new miners ill emerge
463 2014-03-25 10:14:12 <sipa> miners are clients to the full node network, trying to satisfy the blocks they consider valid
464 2014-03-25 10:14:18 <anton000> epscy, new miners will emerge. as long as there's a penny to earn there's always someone willing
465 2014-03-25 10:14:20 <ribasushi> sipa: <ribasushi> "upgrade to bfgcoin 1.0 because X and Y, and OH 50btc for another year"
466 2014-03-25 10:14:23 <wumpus> epscy: stubborn divisions can exist indefinitely
467 2014-03-25 10:14:36 <epscy> Jacques_: if all current miners stopped mining bitcoin right now, how much money would it cost to find another block?
468 2014-03-25 10:14:40 <midnightmagic> ribasushi: That does not make any difference to end-users.
469 2014-03-25 10:14:40 <sipa> ribasushi: and those 50btc will be worthless, as nobody will accept them
470 2014-03-25 10:15:03 <wizkid057> 50 BTC blocks again?! I'm in :D
471 2014-03-25 10:15:08 <sipa> epscy: meh, you'll fimd a few who want ALL BLOCKS
472 2014-03-25 10:15:09 <ribasushi> ^^ QED
473 2014-03-25 10:15:10 <wizkid057> <troll>
474 2014-03-25 10:15:23 <anton000> lol
475 2014-03-25 10:15:34 <Jacques_> Jacques_: money? No idea, but I suspect it would o average be about a week until new blocks would apepar... not the greatest result in history but
476 2014-03-25 10:15:38 <ribasushi> also btc does not seem to be at a point where there are detectable numbers of "end-users"
477 2014-03-25 10:15:49 <epscy> Jacques_: the diff can only drop after 2016 blocks, i'm painting a pretty extreme scenaerio here i realise, but miner centralization does worry me
478 2014-03-25 10:16:05 <Jacques_> epscy: hence the average wait of a week (1013 blocks)
479 2014-03-25 10:16:06 <midnightmagic> aside from the persistent value of hundreds of dollars on the exchanges
480 2014-03-25 10:16:36 <epscy> Jacques_: 1013 blocks?
481 2014-03-25 10:16:58 <epscy> midnightmagic: which you wouldn't be able to transfer on the non mining fork
482 2014-03-25 10:17:09 <Jacques_> epscy: unless they stopped mining on the first block after difficulty adjustment, its safe to assume on average about half way thru the cycle, aka 1013 cycles until dificulty change
483 2014-03-25 10:17:16 <Jacques_> 1013 blocks*
484 2014-03-25 10:17:35 <midnightmagic> epscy: Which probably would never exist except in rhetorical-land anyway.
485 2014-03-25 10:17:38 <epscy> right, 1013 blocks at current difficulty is still kinda a tall order
486 2014-03-25 10:17:45 <anton000> 
ACTION thinking out loudly isnt this supposed to be #bitcoin-dev ?

487 2014-03-25 10:17:47 <Jacques_> but isn't the difficulty stopped from sky-rocketing up or down? sipa ?
488 2014-03-25 10:18:33 <midnightmagic> Jacques_: 4x up, 3/4 down max.
489 2014-03-25 10:18:47 <epscy> which makes the problem worse for the non miners no?
490 2014-03-25 10:18:50 <wumpus> anton000 +1, this is veering to #bitcoin territory
491 2014-03-25 10:18:55 <epscy> anyway this is kinda OT
492 2014-03-25 10:19:04 <epscy> i'm in #bitcoin if anyone wants to follow up
493 2014-03-25 10:19:04 <Jacques_> wumpus: I agree, but, I feel like you'd scare them over there
494 2014-03-25 10:19:11 <wizkid057> well, Eligius won't join the crap fork, so, no worries
495 2014-03-25 10:19:14 <wizkid057> :)
496 2014-03-25 10:19:17 <midnightmagic> yay
497 2014-03-25 10:24:29 <daniel__> sigh, back to work :S
498 2014-03-25 10:24:40 <daniel__> was an interesting conversation haha
499 2014-03-25 10:26:51 <anton000> sorry to be the pooper... but #bitcoin
500 2014-03-25 10:27:50 <Jacques_> so sipa: (looking at https://www.biteasy.com/testnet/transactions/fc129058bebcd4ba2423cc96dd4fa13b65f471e8bd4f78c98023197e52ecc262) that looks like <pubKey> <pubKey> <serializedSig>, no signature at all? :S
501 2014-03-25 10:30:04 <Jacques_> with an[] (0?) on the front
502 2014-03-25 10:52:46 <sipa> Jacques_: the [] is an incorrectly decoded OP_0 (which is necessary due to a quirk in the checkmultisig code; it doesn't do anything)
503 2014-03-25 10:52:55 <sipa> Jacques_: the following two entries are signatures
504 2014-03-25 10:53:08 <sipa> (those starting with 3044/3045)
505 2014-03-25 10:53:21 <sipa> the last one is a serialized script push
506 2014-03-25 10:54:03 <sipa> the serialized script decodes to: 2 02359c6e3f04cefbf089cf1d6670dc47c3fb4df68e2bad1fa5a369f9ce4b42bbd1 0395a9d84d47d524548f79f435758c01faec5da2b7e551d3b8c995b7e06326ae4a 2 OP_CHECKMULTISIG
507 2014-03-25 10:54:17 <sipa> where the two long hex sequences are public keys
508 2014-03-25 14:52:02 <talkb1nary> (Probably more fitting here) if i create a simple gamble site. what would be best practice to track payments? using the internal "database" from the daemon? or querying the lasttransactions every so often?
509 2014-03-25 14:53:08 <sipa> the second, and using that to update the first
510 2014-03-25 14:54:57 <talkb1nary> so best is probably to "outsource" the balances into a DB by querying lasttransactions?
511 2014-03-25 14:56:06 <Jacques_> sipa: thanks for that break down, is the HASH160(OP_2 02359c6e3f.... 0395a9d84..... OP_2 OP_CHECKMULTISIG)   the hash expected?
512 2014-03-25 14:56:41 <sipa> Jacques_: if it isn't the transaction wouldn't be valid, so i assume it is :)
513 2014-03-25 14:56:58 <Jacques_> because I've tried taking the hash160 of that, and it doesn't equate to the multisig address :S
514 2014-03-25 14:57:44 <Jacques_> but I guess thats likely somewhere my fault :)
515 2014-03-25 14:59:55 <stonecoldpat> Jacques_: is this the signature hash included as an input to a transaction? have you included the outputs of the new transaction?
516 2014-03-25 15:00:25 <sipa> stonecoldpat: he's not computing a sighash, just a scripthash
517 2014-03-25 15:00:36 <Jacques_> ^
518 2014-03-25 15:00:38 <stonecoldpat> sipa: ah ok sorry
519 2014-03-25 15:01:04 <Jacques_> hmmm, must be my version constants, the hex is correct
520 2014-03-25 15:01:30 <sipa> you know that hash160(x) is ripemd160(sha256(x)) ?
521 2014-03-25 15:01:36 <Jacques_> I do
522 2014-03-25 15:02:15 <Jacques_> all good, I'm on the right path :)
523 2014-03-25 15:02:16 <Jacques_> cheers
524 2014-03-25 15:13:33 <BlueMatt> cdecker: ping
525 2014-03-25 15:25:16 <cdecker> Pong
526 2014-03-25 15:30:08 <Jacques_> sipa: :D
527 2014-03-25 15:30:19 <Jacques_> now... sigHash...
528 2014-03-25 15:30:44 <sipa> Jacques_: prepare for another level of pain
529 2014-03-25 15:31:37 <Jacques_> I just got the 2L water jug. Musics just entered another 2hr mix
530 2014-03-25 15:31:39 <Jacques_> I'm ready
531 2014-03-25 15:33:01 <hearn> haha
532 2014-03-25 15:33:08 <hearn> take a deep breath .....
533 2014-03-25 15:33:21 <hearn> and watch out for the SIGHASH_SINGLE trap! best of luck!
534 2014-03-25 15:35:15 <jouke> :)
535 2014-03-25 15:36:26 <BlueMatt> cdecker: pm
536 2014-03-25 15:37:17 <bitblender> ;;tlsb
537 2014-03-25 15:37:18 <gribble> Error: "tlsb" is not a valid command.
538 2014-03-25 15:37:26 <bitblender> ;;tslb
539 2014-03-25 15:37:30 <gribble> Time since last block: 49 minutes and 1 second
540 2014-03-25 15:37:45 <ribasushi> the pubkey->address conversion uses multiple hashing rounds - what is the reasoning for this?
541 2014-03-25 15:37:54 <ribasushi> is there a vague security risk by disclosing the pubkey?
542 2014-03-25 15:41:21 <wumpus> ribasushi: well *if* there is an attack on ECDSA at some point, revealing the pubkey decreases security
543 2014-03-25 15:42:35 <t7> what was the longest time between blocks ever?
544 2014-03-25 15:44:10 <gavinandresen> t7: good question. Should be easy to answer, just iterate through the chain looking at block timestamps and find the two the farthest apart...
545 2014-03-25 15:44:28 <gavinandresen> t7: might also be a good question for bitcoin.stackexchange.com
546 2014-03-25 15:44:45 <t7> i will ask
547 2014-03-25 15:44:51 <t7> need some points
548 2014-03-25 15:45:45 <t7> Block 0 was mined 128 hours, 39 minutes and twenty seconds before Block 1.
549 2014-03-25 15:45:48 <christophe> ribasushi: The ripemd hash was mostly for compactness of addresses.
550 2014-03-25 15:46:37 <christophe> Technically, an address is QC-resistant where a pubkey isn't. But that probably won't matter in our lifetimes.
551 2014-03-25 15:47:35 <topynate> christophe: or an address isn't known not to be QC-resistant :)
552 2014-03-25 15:50:23 <epscy> t7: so the first block after the genesis block then?
553 2014-03-25 15:50:32 <t7> yep
554 2014-03-25 15:50:44 <epscy> isn't the timestamp on the genesis dubious or am i misremembering?
555 2014-03-25 15:50:52 <t7> nobody is gonna beat 5 days
556 2014-03-25 15:51:12 <epscy> t7: i would be interested in the next longest blocktime
557 2014-03-25 15:51:17 <t7> 25 hours
558 2014-03-25 15:51:19 <t7> was second
559 2014-03-25 15:51:26 <t7> at block 150k ish
560 2014-03-25 15:51:28 <epscy> oh interesting
561 2014-03-25 15:51:35 <epscy> that's quite a long time really
562 2014-03-25 15:51:39 <t7> yeah
563 2014-03-25 15:52:56 <epscy> so that's like 10 days after the genesis block?, if my math isn't faulty
564 2014-03-25 15:53:55 <t7> 150,000
565 2014-03-25 15:54:06 <arubi> there's no math involved, since block times are irregular
566 2014-03-25 15:54:24 <epscy> well assuming 6 blocks an hour
567 2014-03-25 15:54:31 <epscy> on average
568 2014-03-25 15:54:35 <arubi> obviously this is not the case :D
569 2014-03-25 15:54:46 <epscy> right but normally...
570 2014-03-25 15:54:49 <t7> epscy: well it will be less
571 2014-03-25 15:54:50 <arubi> well yea
572 2014-03-25 15:55:00 <t7> you should factor in the difficulty change :)
573 2014-03-25 15:55:08 <t7> some kinda curve
574 2014-03-25 15:55:18 <epscy> diff change shouldn't have that much of an effect