1 2014-11-06 00:07:25 <sipa> cfields: would it be unacceptably ugly to just have -lgmp inside bitcoin, and link in src/secp256k1/libsecp256k1.o or whatever the filename is?
2 2014-11-06 00:08:36 <cfields> sipa: it's not really a big issue
3 2014-11-06 00:08:43 <sipa> ok
4 2014-11-06 00:13:06 <cfields> sipa: mm, i suppose we'll need yasm as well
5 2014-11-06 00:13:23 <sipa> for now it doesn't matter at all, really
6 2014-11-06 00:13:40 <sipa> as signing isn't particularly performance oriented
7 2014-11-06 00:13:56 <cfields> ok
8 2014-11-06 00:26:53 <gmaxwell> yea, no asm for now.
9 2014-11-06 00:39:15 <ryan-c> does bitcoin have deterministic ecdsa signatures yet?
10 2014-11-06 00:47:15 <phantomcircuit> ryan-c, bitcoin core does not
11 2014-11-06 00:47:18 <phantomcircuit> some clients do
12 2014-11-06 00:48:20 <ryan-c> know if any of them used anything other than rfc6979?
13 2014-11-06 00:49:57 <gmaxwell> ryan-c: plenty to random things.
14 2014-11-06 00:50:11 <gmaxwell> rfc6979 is poorly drafted and it seems a lot more complex than it is.
15 2014-11-06 00:50:26 <gmaxwell> So it was actually really hard to talk some people who are using it into using it.
16 2014-11-06 00:50:59 <gmaxwell> (as opposed to some adhoc scheme)
17 2014-11-06 00:51:16 <ryan-c> happen to have any specific examples?
18 2014-11-06 00:52:02 <gmaxwell> the JS code used by many of the websites like brainwallet.org, for example, do some adhoc determinstic signing.
19 2014-11-06 00:52:16 <ryan-c> i was reading rfc6979 and yeah, it seems convoluted
20 2014-11-06 00:52:26 <gmaxwell> it's really not, but the description sucks.
21 2014-11-06 00:53:04 <gmaxwell> the reason the description sucks is partically because rfc6979 is precisely a previously standardized CSPRNG.
22 2014-11-06 00:53:07 <ryan-c> the brainwallet.org code looked to me like it was using random nonces
23 2014-11-06 00:53:21 <gmaxwell> it's not. (unless they changed it again, wouldn't surprise me)
24 2014-11-06 00:53:38 <sipa> it's supposed to *look* like random nonces!
25 2014-11-06 00:53:44 <gmaxwell> lol
26 2014-11-06 00:55:47 <ryan-c> gmaxwell: brainwallet.org looked to be using bitcoinjs's signature routine, which IIRC is random
27 2014-11-06 00:56:04 <ryan-c> or maybe it was bitaddress i was looking at
28 2014-11-06 00:56:48 <gmaxwell> ryan-c: it's bitcoinjs and it's derandomized at least in the version they were running when I last looked. I know there are like three random functions scattered in the codebase, ...
29 2014-11-06 00:56:56 <gmaxwell> (including two that are insecure)
30 2014-11-06 00:58:52 <PerlPython> exit
31 2014-11-06 00:58:59 <PerlPython> oops
32 2014-11-06 00:59:09 <ryan-c> it looks like it's using some rng object which *appears* to be using SecureRandom from some lib.
33 2014-11-06 01:00:14 <ryan-c> gmaxwell: oh, i see your comments on a github ticket about htat
34 2014-11-06 01:00:48 <cfields> wtf...
35 2014-11-06 01:00:56 <cfields> http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.bz2
36 2014-11-06 01:01:13 <ryan-c> cfields: are they offering to provide you with a download manager?
37 2014-11-06 01:01:36 <cfields> ryan-c: "The sourceforge.net website is temporarily in static offline mode."
38 2014-11-06 01:01:55 <gmaxwell> We're sorry -- the Sourceforge site is currently in Disaster Recovery mode, and currently requires
39 2014-11-06 01:01:59 <gmaxwell> the use of javascript to function. Please check back later.
40 2014-11-06 01:02:04 <ryan-c> lulwat
41 2014-11-06 01:02:18 <cfields> and even more fun...
42 2014-11-06 01:02:20 <cfields> HTTP request sent, awaiting response... 200 OK
43 2014-11-06 01:02:24 <gmaxwell> maybe they meant to write "please try again: We cannot backdoor your host via this transport mechenism"
44 2014-11-06 01:06:27 <cfields> it's completely unobvious that the download fails, as far as i can see. an error response would've been helpful...
45 2014-11-06 01:07:17 <cfields> travis may start failing builds. I suppose the dep-downloader should try the fallback site after the checksum fails too
46 2014-11-06 01:16:44 <cfields> mm, back up now
47 2014-11-06 01:23:06 <cfields> sipa: if you intend to make libsecp usage non-optional, we can de-hackify a good bit of the make stuff. I didn't realize that was the plan
48 2014-11-06 06:52:45 <inian> I running a bitcoind instance on my computer and it is using all my cores of the CPU..is there any way to limit the number of cores used?
49 2014-11-06 06:54:25 <Arnavion> cpulimit / cgroups
50 2014-11-06 06:54:41 <wumpus> -par=<num>
51 2014-11-06 06:59:17 <inian> @arnavion - cpulimit is for linux right? is there anything for mac
52 2014-11-06 06:59:30 <wumpus> I just said
53 2014-11-06 06:59:34 <inian> @wumpus - ./bitcoind -par=1 did not help..is there anything wrong?
54 2014-11-06 07:00:03 <wumpus> what version?
55 2014-11-06 07:00:28 <inian> bitcoin v 0.9.3
56 2014-11-06 07:00:59 <wumpus> can you look for the most recent message Using %u threads for script verification in debug.log?
57 2014-11-06 07:01:17 <wumpus> it should say 1 if you put -par=1
58 2014-11-06 07:02:23 <gmaxwell> inian: you're not explaining how you used it? did you stop it and restart it with that parameter?
59 2014-11-06 07:03:00 <inian> @wumpus I am not getting that message in my debug.log file
60 2014-11-06 07:03:12 <wumpus> ... ok, I can't help you further
61 2014-11-06 07:03:35 <inian> gmaxwell: yes I terminated that instance and re-ran with -par=1
62 2014-11-06 07:05:00 <gmaxwell> inian: it would have been at the top, when it started. There is no possiblity it wouldn't print the message, if it's actually bitcoin you're running.
63 2014-11-06 07:09:20 <inian> this is my debug.log http://pastebin.com/5cGKBSJw
64 2014-11-06 07:19:58 <gmaxwell> ah, okay then its only using one thread.
65 2014-11-06 07:20:35 <gmaxwell> and you say its using multiple cpus?
66 2014-11-06 07:23:00 <wumpus> dah
67 2014-11-06 07:23:10 <wumpus> indeed, it doesn't log the message if no threads are used
68 2014-11-06 07:23:21 <gmaxwell> wumpus: yea, kinda goofy.
69 2014-11-06 07:23:34 <phantomcircuit> inian, are you running bitcoind or bitcoin-qt ?
70 2014-11-06 07:23:55 <phantomcircuit> it's probably better to run with an elevated nice level instead of reducing cores
71 2014-11-06 07:24:05 <phantomcircuit> unless you have a cooling issue
72 2014-11-06 07:24:27 <gmaxwell> phantomcircuit: on some OSes the scheduler is stupid.. perhaps OSX is like that.
73 2014-11-06 07:24:32 <sinetek> shall I fix this?
74 2014-11-06 07:25:04 <phantomcircuit> gmaxwell, i think the os x scheduler isn't great but also isn't entirely stupid as long as you reduce the priority
75 2014-11-06 07:25:20 <inian> gmaxwell: the CPU usage from my activity monitor shows bitcoind is using 400%
76 2014-11-06 07:25:38 <inian> i was running 2 instances of bitcoind to simulate mining
77 2014-11-06 07:25:46 <phantomcircuit> o.o
78 2014-11-06 07:25:47 <phantomcircuit> wat
79 2014-11-06 07:26:19 <inian> phantomcircuit: I am running bitcoind
80 2014-11-06 07:27:57 <wumpus> and you started *both* instances with -par=1?
81 2014-11-06 07:28:12 <inian> yup!
82 2014-11-06 07:28:44 <phantomcircuit> this sounds suspiciously like you have setgenerate true
83 2014-11-06 07:29:27 <wumpus> is there something like top -H for your os, where you can see which threads take the CPU?
84 2014-11-06 07:30:09 <gmaxwell> inian: are you actually running with -gen=1 to mine?
85 2014-11-06 07:30:13 <wumpus> (at least on linux we name the threads to distinguish them, no idea about osx)
86 2014-11-06 07:30:36 <inian> gmaxwell: yes i have set gen=1 in the bitcoin.conf file
87 2014-11-06 07:32:14 <wumpus> that explains it, the miner grabs threads too
88 2014-11-06 07:32:29 <gmaxwell> inian: well don't do that if you don't want it using a lot of cpu... :) ... do we still have knobs to control mining threads anymore?
89 2014-11-06 07:32:43 <phantomcircuit> yes but why
90 2014-11-06 07:33:07 <gmaxwell> I thought we ditched the multithreaded internal mining at some point.
91 2014-11-06 07:33:24 <wumpus> we do if you setgenerate through RPC
92 2014-11-06 07:33:52 <wumpus> no, that never happened
93 2014-11-06 07:34:04 <inian> yes I want to control the number of miner threads..cpuminer has a flag for it..was checking if bitcoind had a similar flag..
94 2014-11-06 07:34:21 <phantomcircuit> what are you even doing cpu mining?
95 2014-11-06 07:34:26 <wumpus> inian: start with -gen=0, then use setgenerate RPC command to start mining with your desired number of threads
96 2014-11-06 07:34:55 <wumpus> OH there's an option -genproclimit too
97 2014-11-06 07:35:00 <wumpus> use -genproclimit=1
98 2014-11-06 07:35:08 <wumpus> I still discover new things every day
99 2014-11-06 07:35:12 <inian> phantomcircuit: i was just looking to play with the source code and wanted to simulate mining to test my code..
100 2014-11-06 07:35:57 <gmaxwell> there yea go.
101 2014-11-06 07:35:58 <wumpus> inian: that's ok - that's the entire reason the internal miner still exists
102 2014-11-06 07:37:55 <sipa> cfields: i dehackified part already in my PR, but please go further :)
103 2014-11-06 07:38:12 <wumpus> I didn't find it at first because in all the other help messages (rpc threads, verification threads) we talk about "threads", however for genproclimit it is suddenly a "processor limit"
104 2014-11-06 07:38:13 <cfields> sipa: done :)
105 2014-11-06 07:38:44 <sipa> cfields: it wasn't the plan to make it nonoptional so soon, but realizing that using it for just signing should be perfectly safe and an improvement over openssl already
106 2014-11-06 07:38:47 <cfields> it actually ended up pretty clean
107 2014-11-06 07:39:07 <sipa> wumpus: genproclimit is from the satoshi days of yoe
108 2014-11-06 07:39:09 <sipa> *yore
109 2014-11-06 07:39:09 <wumpus> (and I first had to brush the dust and cobwebs from it)
110 2014-11-06 07:39:12 <wumpus> yes :)
111 2014-11-06 07:39:24 <cfields> sipa: i'm just narrowing down one last osx bug now, then it should be all green
112 2014-11-06 07:41:45 <cfields> bingo, pushed. sipa: feel free to squash any of those changes into yours
113 2014-11-06 07:42:37 <wumpus> anyone against changing the default for genproclimit to 1 (one core) instead of -1 (all cores)?
114 2014-11-06 07:43:17 <sipa> wumpus: sgtm
115 2014-11-06 07:43:44 <wumpus> (alternatively, I could also remove threading from the internal miner completely)
116 2014-11-06 07:43:52 <sipa> wumpus: sgtm
117 2014-11-06 07:44:14 <wumpus> @gmaxwell already thought that was the case
118 2014-11-06 07:44:25 <wumpus> ok
119 2014-11-06 07:44:37 <moa> amazing how fast that piece of code has become pre-historic
120 2014-11-06 07:45:09 <inian> wumpus: thanks that worked :)
121 2014-11-06 07:45:12 <cfields> wumpus: for someone using it for educational purposes, i should think that single-threaded would make it substantially easier to mess with
122 2014-11-06 07:45:28 <inian> ./bitcoin-cli setgenerate true 1
123 2014-11-06 07:46:00 <wumpus> cfields: exactly
124 2014-11-06 07:46:13 <moa> like seeing a model T drive by
125 2014-11-06 07:46:57 <wumpus> moa: indeed, it's amazing how fast things become pre-historic these days
126 2014-11-06 07:48:26 <moa> but it's still great to see people driving model T's
127 2014-11-06 07:49:23 <sipa> ACTION googles 'model T'
128 2014-11-06 07:49:31 <sipa> Ah,
129 2014-11-06 07:49:59 <wumpus> moa: well technology getting old always seems to go through phases, the first is *yuck, that's outdated*, and soon after a group of people becomes nostalgic for it
130 2014-11-06 07:50:18 <gmaxwell> I don't have an opinion about removing the threading, if the code isn't causing trouble its safe to leave it alone. Or remove it. ::shrugs::
131 2014-11-06 07:50:20 <moa> sniff, i miss cpu minig
132 2014-11-06 07:50:57 <wumpus> gmaxwell: well for now I'm just going to change the default to 1, it's less surprising than *all cores*
133 2014-11-06 07:51:10 <sipa> cfields: hmm, building all of libsepc, including tests and benchmarks?
134 2014-11-06 07:51:22 <sipa> cfields: tests makes sense, if we also run them
135 2014-11-06 07:51:33 <cfields> sipa: nope, just the lib
136 2014-11-06 07:51:43 <sipa> well, no
137 2014-11-06 07:51:44 <gmaxwell> wumpus: makes sense.
138 2014-11-06 07:51:46 <cfields> the tests are built from 'make check'
139 2014-11-06 07:52:27 <sipa> yes, i did a 'make check' in bitcoin, and it also builds the libsecp tests
140 2014-11-06 07:52:46 <cfields> yes, that was done explicitly. Is that not wanted?
141 2014-11-06 07:52:50 <cfields> i assumed it would be
142 2014-11-06 07:52:50 <wumpus> otherwise the default par uses all cores, and the default generate also uses all cores...
143 2014-11-06 07:53:07 <sipa> cfields: ok, very good then :)
144 2014-11-06 07:53:11 <sipa> cfields: but the tests aren't run
145 2014-11-06 07:53:46 <cfields> sipa: feel free to disable that, it's what i assumed you would want
146 2014-11-06 07:53:52 <cfields> sipa: hmm? they run here with 'make check'
147 2014-11-06 07:54:03 <cfields> sipa: sure you've got the newest? I force-pushed about 15 times :)
148 2014-11-06 07:54:03 <sipa> oh, yes, they do!
149 2014-11-06 07:54:11 <sipa> ignore me, i'm barely awake
150 2014-11-06 07:54:15 <sipa> cfields: awesome!
151 2014-11-06 07:55:02 <cfields> sipa: might want to bump the test cycles down for bitcoin though, for those used to running 'make check' constantly
152 2014-11-06 07:56:05 <sipa> right
153 2014-11-06 07:56:38 <cfields> sipa: for some reason bench is made when tests are, need to track that down in the secp build
154 2014-11-06 07:57:06 <sipa> cfields: 'make check' by default builds everything, no, to see whether it all compiles?
155 2014-11-06 07:57:32 <sipa> we can pass --disable-benchmark to libsecp256k1 i guess
156 2014-11-06 07:57:56 <cfields> sipa: yea, i guess you're right
157 2014-11-06 07:58:06 <cfields> i'm barely awake too, headed the other way :)
158 2014-11-06 07:58:50 <sipa> the secp tests take longer than the bitcoin tests... but probably a lot less than the time already spent on building
159 2014-11-06 07:58:57 <sipa> if the builds are cached however...
160 2014-11-06 07:59:47 <cfields> sounds good. make whatever changes you'd like, i just wanted to get it to the point where we could fiddle with it first
161 2014-11-06 07:59:52 <cfields> nnite
162 2014-11-06 07:59:55 <sipa> goodnight!
163 2014-11-06 08:48:42 <moa> sipa: if I have a few tweaks for your libsecp25k1 build system send PR here https://github.com/sipa/secp256k1 ?
164 2014-11-06 08:48:57 <sipa> moa: no, upstream
165 2014-11-06 08:49:02 <CodeShark> sipa: were you able to get the rfc6979 thing to build?
166 2014-11-06 08:49:02 <sipa> github.com/bitcoin/secp256k1
167 2014-11-06 08:49:15 <sipa> CodeShark: haven't gotten to it yet; probably will today
168 2014-11-06 08:49:34 <CodeShark> sipa: I think the ECDSA_sign_ex issue has been fixed
169 2014-11-06 08:49:39 <sipa> good
170 2014-11-06 08:49:50 <CodeShark> it's always generating the same signature for a given key and data and the signature is valid
171 2014-11-06 08:50:35 <moa> thnx
172 2014-11-06 10:57:45 <wumpus> is it safe to lower the wallet's minTxFee now, a year after the minRelayTxFee was lowered? - if so/not so, comment on https://github.com/bitcoin/bitcoin/pull/5209
173 2014-11-06 10:59:14 <sipa> with fee estimation, i guess the main purpose of mintxfee is a safe lower bound on fees to prevent non-confirmation
174 2014-11-06 10:59:23 <sipa> so i guess the question is how good the fee estimation is
175 2014-11-06 10:59:46 <wumpus> it consistenly overestimates in my experience
176 2014-11-06 11:00:26 <wumpus> but as it meant to be a safe lower bound; is it really safe?
177 2014-11-06 11:00:55 <sipa> i don't have experience with the fee estimation code, so i can't tell
178 2014-11-06 11:00:56 <wumpus> is a sufficient part of the network now using 0.9.x?
179 2014-11-06 11:01:03 <wumpus> apart from the fee estimation code
180 2014-11-06 11:02:02 <wumpus> after all, the rationale for changing minTxFee after minRelayTxFee was to avoid generated transactions not getting relayed at all
181 2014-11-06 11:02:34 <sipa> yes, though as blocks are getting more full, the relay fee probably becomes less relevant and the actual voluntary fee more relevant
182 2014-11-06 11:02:46 <sipa> but i don't have any numbers about this
183 2014-11-06 11:05:37 <wumpus> the only thing the safe lower bound needs to guarantee is that transactions aren't (likely) dropped immediately after broadcasting so miners don't even get to see them
184 2014-11-06 11:07:11 <sipa> Luke-Jr: you had some script running to see percentages of node versions?
185 2014-11-06 12:36:40 <jtimon> what's the right way to print a warning?
186 2014-11-06 12:38:03 <jtimon> LogPrintStr() ?
187 2014-11-06 12:58:03 <wumpus> LogPrintf generally
188 2014-11-06 13:53:45 <CodeShar_> sipa: I just pushed the rfc6979 stuff into my master branch - https://github.com/ciphrex/CoinVault/commit/462292635ba7e4f00e122bca14056d020e87fb5b
189 2014-11-06 13:54:00 <sipa> CodeShar_: and i just verified my implementation against yours
190 2014-11-06 13:54:50 <CodeShark> sipa: so they agree?
191 2014-11-06 13:54:54 <sipa> yes
192 2014-11-06 13:54:56 <CodeShark> awesome
193 2014-11-06 14:05:11 <CodeShark> sipa: did you do any benchmark comparisons?
194 2014-11-06 14:05:16 <sipa> no
195 2014-11-06 14:05:22 <sipa> i don't care about signing :)
196 2014-11-06 14:05:23 <CodeShark> not that I was really trying to optimize performance or anything :)
197 2014-11-06 14:05:33 <sipa> nor was i
198 2014-11-06 14:25:42 <JayCie> Hi there, just a small dev question: i launched bitcoind on a dedicated server and it synchronized the 21Go of previous transactions. I want to export this data as CSV. What do you suggest me to do? I looked to the bitcoin-cli tool but I can't find anything to export transactions. Any ideas?
199 2014-11-06 14:27:16 <hearn> CSV?
200 2014-11-06 14:27:25 <hearn> that would be a rather inefficient form to represent the block chain in
201 2014-11-06 14:27:29 <hearn> what do you plan to do with that?
202 2014-11-06 14:28:16 <JayCie> data analysis using hadoop
203 2014-11-06 14:28:33 <JayCie> i tink I can use a different format it's ok
204 2014-11-06 14:28:38 <hearn> you probably want a database store for that
205 2014-11-06 14:28:48 <JayCie> yes it's ok as well
206 2014-11-06 14:29:21 <JayCie> SQL, CSV... Everything is ok for me as long as it's easily accesible from java
207 2014-11-06 14:29:38 <JayCie> (no binaries file)
208 2014-11-06 14:30:05 <JayCie> so is there a way to export the transactions?
209 2014-11-06 14:36:16 <wumpus> sure
210 2014-11-06 14:36:56 <wumpus> for n in 0..height; getblockhash <n>, getblock <n>; end
211 2014-11-06 14:37:08 <hearn> JayCie: a bunch of ways but they tend to get you either binary data or parsed language objects.
212 2014-11-06 14:37:33 <hearn> JayCie: you could check out something like Insight, which is a block explorer. that builds a database that you can then query from a hadoop job
213 2014-11-06 14:37:34 <wumpus> although it's far from the most efficient way of doing that, generally if you want to parse *the entire blockchain* you'd use a tool that parses the block data directly
214 2014-11-06 14:38:03 <wumpus> ie https://github.com/znort987/blockparser
215 2014-11-06 14:38:14 <wumpus> or indeed, insight, abe, etc
216 2014-11-06 14:38:48 <JayCie> Ok ty guys, i gonna try this out
217 2014-11-06 14:38:57 <JayCie> ty for your help :)
218 2014-11-06 15:24:17 <Luke-Jr> ew, when did the Send button get moved to the left side? :x
219 2014-11-06 15:25:08 <sipa> oh noes
220 2014-11-06 16:58:59 <ianks> Are there some must-read resources around security for an application that interfaces with bitcoind?
221 2014-11-06 17:38:57 <Luke-Jr> wumpus: what did you have in mind for changing icon colours easily at runtime?
222 2014-11-06 19:23:25 <jtimon> Luke-Jr I assume templates in the same way the color of main vs testnet/regtest is selected
223 2014-11-06 19:26:52 <sipa> \o/ gpg 2.1 released (with ecc support...)
224 2014-11-06 19:27:40 <pigeons> how long will fedora disable it
225 2014-11-06 19:29:51 <gmaxwell> pigeons: the main ECC support is NIST curves which fedora no longer disables. ... will be interesting to see if they remove the ed25519 support.
226 2014-11-06 19:31:27 <sipa> seems they have curve25519 (which only does ecdh) rather than ed25519
227 2014-11-06 19:32:38 <sipa> ah, i misread; no, ed25519
228 2014-11-06 19:45:46 <Diablo-D3> gmaxwell: why are they disabling 25519?
229 2014-11-06 19:59:23 <Luke-Jr> Diablo-D3: Fedora/RedHat's lawyers have some weird thing against cryptography (they claim patent fears, but.. yeah)
230 2014-11-06 20:01:06 <pigeons> then they said, "ok if they are NIST reccomended, we'll enable them" lol, right while more info was appearing about Dual_EC_DRBG
231 2014-11-06 20:02:37 <sipa> the gpg guys seem to want ed25519/curve25519, but those aren't standardized in openpgp yet
232 2014-11-06 20:02:42 <sipa> while the nist curves are
233 2014-11-06 20:02:44 <sipa> no clue why
234 2014-11-06 20:15:25 <sinetek> could someone help a noob make his pull request?
235 2014-11-06 20:33:49 <Gozarian> does the bare multisig m of convention limit of m <= 3 hold for both uncompressed and compressed public keys?
236 2014-11-06 20:34:11 <Gozarian> * m of n
237 2014-11-06 20:34:35 <coutts> hi #bitcoin-dev. i am interested in helping out, where is the best place for noobs to start? appreciate any links provided, thanks.
238 2014-11-06 20:34:39 <Luke-Jr> Gozarian: yes
239 2014-11-06 20:35:05 <gmaxwell> sipa: because no one was even asking for it prior to the recent concern about the NSA... and ed25519 is, of course, incompatible with generic implementation stuff for other curves, so it couldn't just be dropped in as just another curve identifier.
240 2014-11-06 20:36:50 <Luke-Jr> coutts: https://bitcoin.org/en/development
241 2014-11-06 20:37:06 <coutts> Thanks Luke-Jr.
242 2014-11-06 20:37:14 <Luke-Jr> particularly https://bitcoin.org/en/developer-documentation
243 2014-11-06 20:37:15 <Gozarian> luke-jr: is the limit purely a function of script byte length?
244 2014-11-06 20:37:22 <Luke-Jr> Gozarian: no.
245 2014-11-06 20:38:49 <Gozarian> sipa posts here http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses that "standardness rules only allow up to n=3" for raw multisig
246 2014-11-06 20:40:42 <Luke-Jr> Gozarian: I'm not sure why you think that implies anything re byte length or compressed vs uncompressed keys
247 2014-11-06 20:41:38 <Gozarian> but the followup answer by amaclin below sipa's answer links to a 20-of-20 bare multisig redemption - is that just relayed by a miner allowing for "non-standard" scripting?
248 2014-11-06 20:42:24 <sipa> "relayed by a miner" makes no sense
249 2014-11-06 20:42:30 <sipa> node relay, miners mie
250 2014-11-06 20:43:03 <sipa> Gozarian: those are perfectly valid, just nom standard
251 2014-11-06 20:43:25 <sipa> validityis what matters for being alloed in a block
252 2014-11-06 20:43:49 <sipa> standardness is whether most nodes and miners in the network will accept it into a block
253 2014-11-06 20:44:24 <Luke-Jr> standardness is scripts well-defined for common use. IsStandard is more narrow :P
254 2014-11-06 20:44:32 <Gozarian> ...relayed by a node...
255 2014-11-06 20:45:37 <Luke-Jr> hopefully miners have all turned off bare multisig by now anyway
256 2014-11-06 20:47:42 <Gozarian> ...so if I want to have a non-standard but well-defined/valid script recorded in a block, would using a higher txn fee be the best route?
257 2014-11-06 20:49:06 <Gozarian> luke-jr: you're saying only use p2sh? bare multisig is deprecated?
258 2014-11-06 20:49:45 <sipa> p2sh is much more flexible and less burdensome to the network
259 2014-11-06 20:50:16 <sipa> and higher fee: maybe, but i doubt it matters
260 2014-11-06 20:53:02 <Gozarian> sipa: yes, its much more flexible and keeps the blockchain size smaller, but it's also more burdensome to me the programmer to sync/manage the scripts/hashes off chain between parties. ;)
261 2014-11-06 20:54:25 <Luke-Jr> Gozarian: txn fees usually don't matter if nodes don't want to relay/mine it
262 2014-11-06 20:54:38 <Luke-Jr> p2sh is the only way multisig is in real world use afaik
263 2014-11-06 20:55:45 <Luke-Jr> Gozarian: consider that you can't support addresses with bare multisig
264 2014-11-06 20:55:56 <Luke-Jr> and most bitcoin users today do use addresses, for better or worse
265 2014-11-06 20:57:38 <Gozarian> very good point.
266 2014-11-06 21:03:42 <Gozarian> do you guys have a good recommendation for a program or technique to investigate and decompile a raw txn script to readable assembly (i.e. OP_ words / addresses)?
267 2014-11-06 21:04:17 <Luke-Jr> Gozarian: bitcoin-tx probably can do it
268 2014-11-06 21:04:29 <Gozarian> is there an online block explorer with it?
269 2014-11-06 21:05:44 <Luke-Jr> no
270 2014-11-06 21:06:56 <Gozarian> I'm surprised, wouldn't something like that be a useful tool for devs?
271 2014-11-06 21:11:13 <Luke-Jr> Gozarian: script disassembly is kinda not related to the idea of a block explorer
272 2014-11-06 21:11:38 <Luke-Jr> also, block explorers are expensive to maintain/operate
273 2014-11-06 21:17:17 <Gozarian> Luke-Jr: I think its related... the current block explorers show the raw input/output scripts at the moment. I think it would be more informative if they were decompiled.
274 2014-11-06 21:44:13 <BlueMatt> petertodd: ping