1 2015-04-12 00:23:16 <andytoshi> sipa: in src/eckey_impl.h:32, should that `return 0` be something else?
  2 2015-04-12 00:23:55 <andytoshi> oh, no, zero means fail..
  3 2015-04-12 00:26:17 <andytoshi> oh, i see :) there was a bug, but it was in my rust bindings, not libsecp256k1
  4 2015-04-12 00:27:43 <sipa> :)
  5 2015-04-12 00:30:26 <andytoshi> i just learned today that kcov works for rust code (and actually better than C it seems; it does weird things with function definitions), been making sure every error path is hit in rust-secp256k1's unit tests
  6 2015-04-12 00:30:48 <thufir> rust-lang?
  7 2015-04-12 00:30:56 <andytoshi> and through some copy-paste-incomplete-update mistake, i was only checking for parse errors for compressed keys, not uncompressed ones
  8 2015-04-12 00:31:01 <andytoshi> thufir: yes, i am apoelstra on #rust
  9 2015-04-12 00:31:31 <thufir> oh thank heavens.. i want to port my project to rust from python but rust wasn't ready. nice to see people are getting the encryption libraries there
 10 2015-04-12 00:33:21 <thufir> Rust is /the/ language of the future. good work guys. deprecates the Cs, the java/c#/gos, even the pythons once you implement yield from :)
 11 2015-04-12 00:35:56 <thufir> sorry for off topic, but a perfect language (unlike python, interpreter lock. interpreter even) whose control and origin is decentralized is a natural bed fellow to bitcoin. so if you already didn't know you are working on the only other thing as important as bitcoin... rust
 12 2015-04-12 00:36:19 <thufir> well now you do, so thanks. anyways i stop distracting now
 13 2015-04-12 00:36:31 <sipa> what does this have to do with decentralization
 14 2015-04-12 00:36:47 <thufir> go, java, c# are controlled due to patents by u.s corporations
 15 2015-04-12 00:37:01 <sipa> bitcoin's rules were also set in a "centralized" way, by satoshi
 16 2015-04-12 00:37:05 <thufir> python isn't quite good enough, it is the best by default, but not perfect
 17 2015-04-12 00:37:22 <thufir> true..., but no one controls them now
 18 2015-04-12 00:38:00 <thufir> without centralized control, it can evolve freely, etc. can't really be used except for freedom.
 19 2015-04-12 00:39:02 <CodeShark> is this another case of "all I've got is a hammer"?
 20 2015-04-12 00:39:10 <sipa> yes
 21 2015-04-12 00:39:10 <thufir> oh, and Cs would be better except python wins becuase memory safety... which is very needed in this post-snowden world :)
 22 2015-04-12 00:39:39 <thufir> nah, maybe it will be rust, python, and sh scripts... but go is dead luckily thanks to rust, etc.
 23 2015-04-12 00:40:46 <sipa> as if there should be just one programming language for all purposes
 24 2015-04-12 00:41:39 <thufir> yea, probably sh scripting won't be replaced. but if you understand rust you understand how both the Cs and the Java/Go/C#s are deprecated.  Maybe not pythons, scriptie languages for quick stuff, etc.
 25 2015-04-12 00:41:42 <sipa> i'm sure go is dead thanks to rust in exactly the same way Java is dead to C#
 26 2015-04-12 00:41:55 <thufir> java competes with c# nothing fundementally different
 27 2015-04-12 00:41:59 <thufir> rust is fundementally different
 28 2015-04-12 00:42:22 <sipa> lol
 29 2015-04-12 00:42:23 <thufir> no runtime. it is C/C++/Cxx11whatever... and it is java/c#/go.
 30 2015-04-12 00:42:25 <sipa> please
 31 2015-04-12 00:43:01 <thufir> ok, to each his own ideas, but I think many founding rust members from mozillia team would concur with me as to its purpose.
 32 2015-04-12 00:43:23 <sipa> i am by no means saying that rust is bad (i only hear good things about it)
 33 2015-04-12 00:43:37 <jrick> rust is very very good but there actually are problems where a GC is the best solution
 34 2015-04-12 00:43:48 <jrick> many lock-free data structures can only be implemented with a GC
 35 2015-04-12 00:44:10 <sipa> by thinking that it will deprecate other languages because of technical merits is delusional imho :)
 36 2015-04-12 00:44:43 <CodeShark> people still use cobol, ferchrissakes
 37 2015-04-12 00:44:48 <thufir> jrick: i suppose, but then someone will make a gc library for rust i imagine.
 38 2015-04-12 00:45:03 <sipa> CodeShark: haha
 39 2015-04-12 00:45:38 <thufir> i'm sure new better stuff with come out, but rust will deprecate all before for serious projects. things like cobol etc will still be interesting for ideas, etc, but for seriuos work the choice will be clear: rust.
 40 2015-04-12 00:46:20 <sipa> cobol is not interesting in any way
 41 2015-04-12 00:46:22 <thufir> sipa: it is a fine line between delusional and visionary :)
 42 2015-04-12 00:46:31 <sipa> it used for legacy reasons
 43 2015-04-12 00:46:31 <thufir> LOL :) you got me there
 44 2015-04-12 00:46:43 <thufir> i was thinking more haskel, etc,
 45 2015-04-12 00:47:00 <thufir> lisps, etc
 46 2015-04-12 00:47:33 <sipa> anyway, let's not get into a language flame here. sorry if i helped it turn into one
 47 2015-04-12 00:48:34 <thufir> agreed. its hard for smart people to not bump heads, think we didn't even approach flamage this time... well, except from cobols perspective, lol :)
 48 2015-04-12 01:00:37 <CodeShark> "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -Edsger W. Dijkstra
 49 2015-04-12 01:00:54 <CodeShark> he wrote this in 1975, yet it's still legal
 50 2015-04-12 01:00:55 <CodeShark> what gives?
 51 2015-04-12 01:01:20 <Meisterbrau> The world is truth; the universe is opinion....Marcus Aurelius
 52 2015-04-12 01:04:29 <CodeShark> that's only because he didn't have rockets and telescopes and general relativity and quantum mechanics :p
 53 2015-04-12 01:04:53 <thufir> prime numbers are a universal truth
 54 2015-04-12 01:05:19 <CodeShark> I think it's been mistranslated
 55 2015-04-12 01:05:26 <CodeShark> in latin, universe literally means "one turn"
 56 2015-04-12 01:06:00 <CodeShark> the term carries far different connotations today
 57 2015-04-12 01:57:39 <cfields> CodeShark: haha, my first paid gig was cobol
 58 2015-04-12 02:16:23 <CodeShark> cfields: my condolences :p
 59 2015-04-12 02:16:54 <cfields> CodeShark: even worse, it was some crazy win32 environment
 60 2015-04-12 02:17:28 <sipa> cfields: oh, now it all bakes sense... sory to hear that
 61 2015-04-12 02:17:40 <sipa> did you get them to pay damages?
 62 2015-04-12 02:17:54 <cfields> sipa: lol, for crippling my mind?
 63 2015-04-12 02:18:12 <CodeShark> Dijkstra is wrong about BASIC, though - that is what I started with and I've managed to regenerate at least a little bit if not completely
 64 2015-04-12 02:18:14 <CodeShark> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
 65 2015-04-12 02:18:28 <sipa> hehe
 66 2015-04-12 02:20:19 <sipa> basic was also my first language
 67 2015-04-12 02:20:25 <sipa> after dutch
 68 2015-04-12 02:20:33 <gmaxwell> CodeShark: you went off to write your own wallet; so I dunno about that sanity part!
 69 2015-04-12 02:20:52 <CodeShark> gmaxwell: the satoshi wallet was driving me nuts :p
 70 2015-04-12 02:23:06 <andytoshi> uh oh, i also started with BASIC and went off to write my own wallet..
 71 2015-04-12 02:23:37 <sipa> i never wrote a wallet; i just rewrote all the rest :p
 72 2015-04-12 02:23:46 <andytoshi> hahahaha
 73 2015-04-12 02:24:31 <CodeShark> sipa: that's why I initially stopped at the wallet - everything else was there :)
 74 2015-04-12 02:26:58 <sipa> hehe
 75 2015-04-12 02:29:06 <cfields> gmaxwell: well, they say to never implement your own crypto, so i'm pretty sure you and sipa must be the insane ones :)
 76 2015-04-12 02:29:37 <CodeShark> cfields: to be fair, I even went as far as writing my own multiprecision arithmetic library :p
 77 2015-04-12 02:29:57 <CodeShark> so I admit, I am a little crazy
 78 2015-04-12 02:30:17 <sipa> cfields: oh, i mostly write other people's crypto.. i don't trust it enough to use myself :D
 79 2015-04-12 02:30:37 <CodeShark> sipa: I felt the same way about my own wallet initially :p
 80 2015-04-12 02:30:48 <cfields> CodeShark: that is crazy... you probably didn't even do the BigNum bugs correctly :p
 81 2015-04-12 02:31:02 <cfields> sipa: haha
 82 2015-04-12 02:31:38 <CodeShark> I've gone back to using OpenSSL for commecial projects, though
 83 2015-04-12 02:32:11 <CodeShark> bugs and all
 84 2015-04-12 02:32:21 <cfields> no one gets fired for using OpenSSL?
 85 2015-04-12 02:32:38 <CodeShark> well, it's certainly been more tested than my stuff
 86 2015-04-12 02:33:17 <cfields> CodeShark: sure, that was tongue-in-cheek. That's very smart, it's just kinda funny given the current climate
 87 2015-04-12 02:37:43 <CodeShark> in sipa's case reimplementing secp256k1 verification had tangible performance benefits
 88 2015-04-12 02:38:11 <CodeShark> in my case I was trying to write signers for microcontrollers
 89 2015-04-12 02:38:28 <sipa> well we want to get rid of openssl for other reasons than performance
 90 2015-04-12 02:38:43 <gmaxwell> not just performance, turns out everyone elses code is scarry untested garbage. With hundreds of hours of work we've been able to create a bunch of scarry /tested/ garbage :)
 91 2015-04-12 02:42:35 <sipa> gmaxwell: hope you mean scary and not scarry
 92 2015-04-12 02:43:10 <cfields> openssl's code could definitely be described as scarry
 93 2015-04-12 02:43:29 <CodeShark> the way I see it there are basically four factors: security, performance, size, and how tested it is...although this last point might also fit under security
 94 2015-04-12 02:44:08 <sipa> CodeShark: well for bitcoin there is another: consistent behaviour
 95 2015-04-12 02:44:13 <CodeShark> oh, right
 96 2015-04-12 02:46:35 <CodeShark> I suppose consistent behavior and how tested it is could be labeled together as "correctness"
 97 2015-04-12 02:50:05 <sipa> right, but correctness depends on what it is used for
 98 2015-04-12 02:55:47 <andytoshi> sipa: in libsecp256k1 how can i add a test that'd detect memcpy'ing from a NULL pointer?
 99 2015-04-12 02:55:57 <andytoshi> i guess just do it and assume it'll segfault in the test binary?
100 2015-04-12 02:56:15 <sipa> andytoshi: yeah...
101 2015-04-12 02:57:10 <gmaxwell> 'tested' has many dimensions; there is how reviewed something is, how reviewable it is,  what level of formal proof there is,  what level of testing, etc.
102 2015-04-12 13:30:45 <aliakbar> hi everyone..why does bitcoind fail to initialize block database when i specify datadir inside the conf-file?
103 2015-04-12 13:31:49 <sipa> write access? disk full?
104 2015-04-12 13:31:58 <sipa> what filesystem is the datadir on?
105 2015-04-12 13:34:34 <aliakbar> what do you mean by filesystem?
106 2015-04-12 13:34:47 <aliakbar> im on ubuntu
107 2015-04-12 13:35:32 <aliakbar> yesterday i had a similar problem where it said theres some problem with boost::filesysem::space
108 2015-04-12 13:36:04 <sipa> that means you're out of disk space
109 2015-04-12 13:36:22 <aliakbar> i try starting a regtest peer via [bitcoind -regtest -daemon -conf="/home/aliakbar/bctestnet/node0/bitcoin.conf"]
110 2015-04-12 13:38:05 <aliakbar> if it was a disk space problem then why does the error disappear when i delete datadir from conf and pass it as a command line option?
111 2015-04-12 13:38:19 <sipa> that's strange, indeed
112 2015-04-12 13:40:21 <aliakbar> like when i pass [bitcoind -regtest -daemon -conf="/home/aliakbar/bctestnet/node0/bitcoin.conf" -datadir="/home/aliakbar/bctestnet/node0"] the server starts without any error
113 2015-04-12 13:41:48 <aliakbar> on [https://en.bitcoin.it/wiki/Running_Bitcoin] it says you can implement any command line option without the "-" character inside the conf-file..but obviously its not that easy
114 2015-04-12 13:42:32 <sipa> and if you do it the other way around?
115 2015-04-12 13:42:38 <sipa> only pass datadir
116 2015-04-12 13:42:46 <sipa> it will use the conf file in that directory
117 2015-04-12 13:43:40 <aliakbar> ok I'll try ..you mean via [bitcoind -regtest -datadir="/home/aliakbar/bctestnet/node0"] only right?
118 2015-04-12 13:43:47 <sipa> yes
119 2015-04-12 13:43:54 <aliakbar> kk..sec
120 2015-04-12 13:46:17 <aliakbar> you were right that worked
121 2015-04-12 13:48:27 <aliakbar> I have to add..starting the server with datadir inside conf worked without any problem previously ...wonderin how in a sudden its returning an error
122 2015-04-12 13:56:24 <aliakbar> can someone give a clue how to start multiple nodes without having to pass a long command everytime  (aside from a bash script)?
123 2015-04-12 13:57:07 <aliakbar> is it appropriate to set aliases? and what do i need to consider regarding different aliases for different nodes?
124 2015-04-12 13:58:20 <sipa> i would create a bash script :)
125 2015-04-12 15:02:48 <harding> sipa: saw your email about setgenerate; I'll make a PR for the bitcoin.org dev docs later today.  Thanks for pointing that out!
126 2015-04-12 15:09:55 <sipa> harding: thanks!
127 2015-04-12 15:16:06 <jonasschnelli> jgarzik: so you would prefer rpc extension over manipulating of the rpc dispatch table like https://github.com/bitcoin/bitcoin/pull/5744 instead of the signaling solution?
128 2015-04-12 15:17:48 <jgarzik> jonasschnelli, It's mainly an issue of operating at the JSON level versus HTTP URI level
129 2015-04-12 15:19:14 <jgarzik> jonasschnelli, Our HTTP interface to JSON-RPC essentially just encapsulates JSON-RPC.  Keeping the HTTP portion of the JSON-RPC interface as simple as possible and pushing complexity into the JSON handling maintains the current model - which can have useful payback down the road
130 2015-04-12 15:20:57 <sipa> having separate URLs essentially means having several independent JSON-RPC services
131 2015-04-12 15:21:08 <sipa> that may make sense if you want independent authentication for them
132 2015-04-12 15:21:18 <jonasschnelli> jgarzik: Agree. But #6006 (https://github.com/bitcoin/bitcoin/pull/6006/files) would reuse most of the JSON-RPC stack... the signaling hooks in where we have parsed JSON and it will allow to return a JSON Object.
133 2015-04-12 15:21:31 <sipa> which may be right for wallet/blockchain separation, especially if there are multiple wallets
134 2015-04-12 15:21:44 <jgarzik> nod
135 2015-04-12 15:22:06 <jgarzik> speaking of auth, we should switch to digest
136 2015-04-12 15:22:10 <jgarzik> by default
137 2015-04-12 15:27:11 <jgarzik> I wonder if a bot could help sweep trivial changes for Cory, making an "ACK trivial" trigger a copy into the trivial tree + closing the PR.
138 2015-04-12 15:32:38 <Luke-Jr> well, it'd be better if trivial stuff got PR'd directly to that tree instead
139 2015-04-12 15:45:55 <jgarzik> Luke-Jr, agree
140 2015-04-12 15:46:03 <jgarzik> Luke-Jr, it's inevitable that people will submit to the main tree
141 2015-04-12 15:46:32 <jgarzik> once the project scales up, I think you'll see kernel-like system where various maintainers collect certain types of changes, then push
142 2015-04-12 15:46:44 <Luke-Jr> hopefully
143 2015-04-12 16:11:22 <jonasschnelli> another question is how "okSafeMode" (-disablesafemode) should act in a post current wallet world
144 2015-04-12 16:12:10 <sipa> make RPCs query the safemode state directly, if they need to?
145 2015-04-12 16:12:18 <sipa> and get rid of the table entry
146 2015-04-12 16:13:09 <jonasschnelli> Agree. Will do another PR if "Push down RPC reqWallet flag #5992" gets merged.
147 2015-04-12 16:13:24 <jonasschnelli> or include... hmm....
148 2015-04-12 16:46:28 <phantomcircuit> Luke-Jr, there's no limit besides block size on how many 0 value outputs the coinbase can have is there?
149 2015-04-12 16:48:32 <jgarzik> jonasschnelli, +1 what sipa said
150 2015-04-12 16:48:42 <jgarzik> jonasschnelli, if you include, make it a separate commit :)
151 2015-04-12 16:48:52 <jonasschnelli> ;) okay. I try
152 2015-04-12 16:50:50 <aliakbar> API QUESTION  - why does one get the wrong peer "addr" after calling getpeerinfo while the peer has the correct port-no. specified inside the conf-file?
153 2015-04-12 16:51:28 <aliakbar> Is it the right place to ask this question?
154 2015-04-12 16:56:11 <ScarfFace> hey everybody, I have a deeper look into payment channels currently, I searched, but what is the current status on tx maleability?
155 2015-04-12 16:57:07 <sipa> transactions are malleable.
156 2015-04-12 16:59:13 <ScarfFace> yea, that's kind of the problem, as it allows hostage-situations within multisignatur addresses
157 2015-04-12 17:00:01 <ScarfFace> I have seen some propositions for fixing it, but I have not seen anything like a status page, how long it might take until this actually gets implemented
158 2015-04-12 17:04:10 <ScarfFace> https://bitcointalk.org/index.php?topic=905964.0 - OP summarizes this quite nice, but he doesn't get any satisfactory answer unfortunately
159 2015-04-12 17:07:18 <ScarfFace> in the lighting network whitepaper is a proposal for a new OP code that wouldn't allow malleability, but I wonder if the main-dev's have any plans implementing it anywhere soon
160 2015-04-12 17:08:55 <phantomcircuit> ScarfFace, it's far too soon to understand whether a new op code w/ softfork makes sense
161 2015-04-12 17:09:29 <phantomcircuit> people are still working to convince themselves that lightning is secure (initial thoughts seem to be very positive, but still)
162 2015-04-12 17:10:56 <ScarfFace> Yea there are many downsides, you would either need to be perma-online with a device that ensures broadcasting the right transactions, or trust a third party with it, which is of course undesirable ...
163 2015-04-12 17:11:32 <ScarfFace> but tbh I see the future in a system like that, dont know if that one for sure, but they made a point with bitcoin not scalable the way it is currently, no matter which block size
164 2015-04-12 17:11:56 <jgarzik> well BIP65 or something like it is definitely wanted
165 2015-04-12 17:12:13 <jgarzik> not sure if that's the opcode lightning wants
166 2015-04-12 17:12:24 <gmaxwell> jgarzik: no, it needs new sighash flags.
167 2015-04-12 17:12:59 <phantomcircuit> gmaxwell, oops right
168 2015-04-12 17:13:05 <ScarfFace> BIP65 is a nice-to-have for lightning I think, but malleability is a must-change for it to work initially
169 2015-04-12 17:13:30 <gmaxwell> Which I assume we'll get something in that space eventually; but it's very new. It's strictly more complex than micropayment hubs, which is the idea it builds on; which haven't been built.
170 2015-04-12 17:13:55 <gmaxwell> ScarfFace: you misunderstand; lightning actually _requires_ extreme malleability.
171 2015-04-12 17:14:20 <ScarfFace> oh?
172 2015-04-12 17:14:41 <ScarfFace> I thought it would make the refund tx unspendable
173 2015-04-12 17:14:53 <gmaxwell> (and the sighash flags are to enable greater mallability so you can rewrite refunds)
174 2015-04-12 17:15:30 <aliakbar> Hey guys, in which irc chat can i post my api question?
175 2015-04-12 17:15:56 <ScarfFace> I thought the sighash will basically remove the signature out of the txid, resulting in a unique txid?
176 2015-04-12 17:15:58 <gmaxwell> aliakbar: I don't understand your question.
177 2015-04-12 17:16:44 <gmaxwell> ScarfFace: no, you _cannot_ have a unique txid which is unique against a malicious counterparty. It's fundimentally impossible.
178 2015-04-12 17:17:33 <ScarfFace> But isn't this only the case because of the curve of the signing algorithm? The rest of the txdata can be assumed constant?
179 2015-04-12 17:17:37 <gmaxwell> ScarfFace: so instead it wants sighash flags that leave the input txids out of the signatures; which creates replay vulnerabilties; so there are details that have to be coped with.
180 2015-04-12 17:17:59 <aliakbar> ive started to instances of bitcoind with separate conf-files & thus different ports...i do addnode node B from node A and do getpeerinfo from both nodes and get a wrong addr argument for node A
181 2015-04-12 17:18:32 <ScarfFace> Ah I see, I guess I have to take a deeper look into sighashes first aswell then ... is there a discussion thread on git or somewhere else about this already?
182 2015-04-12 17:18:47 <gmaxwell> ScarfFace: _no_, the users can just sign again. No linear map cryptosystem gives a unique signature; and the signers themselves can just change the data they're signing.
183 2015-04-12 17:19:31 <gmaxwell> aliakbar: saying "wrong" is not useful. I can't hwlp you with that.
184 2015-04-12 17:19:43 <gmaxwell> Is it just that you're seeing the inbound ephemeral port?
185 2015-04-12 17:20:33 <ScarfFace> gmaxwell: ty for elaborating, do you have any good resources to go through maybe?
186 2015-04-12 17:21:57 <aliakbar> gmaxwell: by wrong i mean this - node A has port 12222 and has added node B with port 22222 ..after getpeerinfo on behalf of node B i get a port no for A different from 12222
187 2015-04-12 17:22:37 <aliakbar> gmaxwell: ive implemented these port no. in corresponding conf-files that are used to start each node
188 2015-04-12 17:24:22 <aliakbar> gmaxwell: SCREENSHOT https://www.dropbox.com/s/68vi44kc1tsinvp/lil_net_3.jpg?dl=0
189 2015-04-12 17:32:59 <aliakbar> gmaxwell: do you understand my point?
190 2015-04-12 17:56:16 <gmaxwell> aliakbar: thats the ephemeral port used for an outbound connection.
191 2015-04-12 17:59:45 <aliakbar> gmaxwell: THANKS a lot .. I'll do some research on that..i'll disturb again if any questions are left
192 2015-04-12 18:04:29 <phantomcircuit> there isn't a limit on the total size of the coinbase transaction is there?
193 2015-04-12 18:04:49 <phantomcircuit> the miner can in theory generate a block with a 100KB+ coinbase transaction
194 2015-04-12 18:05:42 <gmaxwell> phantomcircuit: ~1mb, but many miners will fail if its over 6kb.
195 2015-04-12 18:06:09 <ScarfFace> fail?
196 2015-04-12 18:06:31 <phantomcircuit> ScarfFace, produce incorrect results and/or not produce results at all
197 2015-04-12 18:07:23 <ScarfFace> ah I see ... but in theory they could artifically reduce the remaining size by adding 900kb of junk
198 2015-04-12 18:07:30 <ScarfFace> into each block
199 2015-04-12 18:07:32 <gmaxwell> e.g. avalon1 drops to 1% of it's hashrate if the size is over some limit (though that one might be 20kb)
200 2015-04-12 18:08:53 <gmaxwell> avalon2 has a worse limit; knc had one but I thought it got fixed. etc.. it's just due to extranonce updates being 'too slow' on some embarssingly slow microcontroller. It got better when cgminer improved their sha2 implementation to not be embarassingly slow; but lots of things have old code, and there are still limits.
201 2015-04-12 18:09:35 <ScarfFace> ah, so it could be fixed - ofc no one is really interested in putting man-hours in there
202 2015-04-12 18:10:10 <ScarfFace> but on the other hand it would be beneficial to all miners, if the remaining space in each block is like 50kb
203 2015-04-12 18:10:25 <ScarfFace> increasing tx fees susbstantially
204 2015-04-12 18:10:34 <gmaxwell> most of the mining ecosystem is checked out most of the time; and least effort possible when they do anything facing the bitcoin ecosystem. "Hey, you're kinda screwing up the bitcoin network" "So? my magical machine still craps money just fine!" (no... I'm totally not jaded.)
205 2015-04-12 18:12:00 <ScarfFace> Good they don't do it, but actually I see a huge incentive for them to start with it
206 2015-04-12 18:12:19 <ScarfFace> beside the fact it is not possible because of the hardware
207 2015-04-12 22:21:54 <lechuga_> sipa: thx for the thorough test cases for bip66