1 2015-02-04 00:15:39 <rusty> sipa: yeah, DER encoding sucks.
  2 2015-02-04 00:20:49 <jtimon> mhmm, I'm not sure what can I do about this on my PR... https://travis-ci.org/bitcoin/bitcoin/jobs/49370647#L9551
  3 2015-02-04 00:38:23 <rusty> sipa: I don't understand Pieter's "a much cleaner solution" comment.  So basically, a signature fail would always abort the script unless the signature was empty?
  4 2015-02-04 00:38:38 <sipa> rusty: i'm Pieter, btw
  5 2015-02-04 00:38:46 <sipa> yes
  6 2015-02-04 00:39:07 <rusty> sipa: Ah, that makes sense :)
  7 2015-02-04 00:39:20 <sipa> that unifies the invalid-encoding and valid-encoding-but-invalid cases
  8 2015-02-04 00:39:21 <rusty> sipa: You're damn productive, I assumed there were two of you.
  9 2015-02-04 00:39:36 <sipa> LOL
 10 2015-02-04 00:39:43 <cfields> jtimon: hmm, looks like cache isn't being used for some reason
 11 2015-02-04 00:39:54 <cfields> jtimon: i'll have a look when i'm done with what i'm working on atm
 12 2015-02-04 00:40:17 <rusty> sipa: Yeah, I like that.  I just implemented integer decoding, FWIW, and it's not *that* bad.  But simplicity wins.
 13 2015-02-04 00:41:16 <sipa> rusty: so, right now, the _only_ sane way to implement things is to first have a prepass check that checks for encoding sanity (and can return bip66 failure), then parse the signature (which is guaranteed to succeed), and then validate (which causes opcode failure but not script failure)
 14 2015-02-04 00:41:39 <sipa> and the 33-byte limit doesn't fix that
 15 2015-02-04 00:42:01 <jtimon> thanks cfields
 16 2015-02-04 00:42:48 <sipa> rusty: if we'd reject everything that is not ecdsa-valid (in terms of ranges of arguments), you'd be certain that you could just parse the sig (which casues bip66 failure if it fails), and then validate (which causes opcode failure but not script failure)
 17 2015-02-04 00:43:03 <rusty> sipa: yeah, I was just trying to replace the "> 73" check, not be that ambitious.
 18 2015-02-04 00:43:20 <rusty> sipa: OK, well, I have a patch if you're interested.  Needs testing....
 19 2015-02-04 00:43:24 <sipa> rusty: if there were no time pressure, i'd be all for it
 20 2015-02-04 00:43:44 <sipa> it's "neater", but doesn't solve anything fundamental
 21 2015-02-04 00:43:49 <rusty> sipa: yeah, a bad time to bikeshed....
 22 2015-02-04 00:45:40 <sipa> sdaftuar: sorry for spelling your name incorrectly in my mail
 23 2015-02-04 00:47:03 <rusty> sipa: so, you're dropping BIP66 altogether?  Or just stick with the current version for now, and another soft fork later?
 24 2015-02-04 00:47:50 <sipa> rusty: stick with the current proposal
 25 2015-02-04 00:49:40 <rusty> sipa: OK... I'll stop bikeshedding over the > 73 length check then, since it should eventually die (does the script-fail-on-sigfail-nonempty-sig have a BIP?)
 26 2015-02-04 00:50:40 <sipa> no, it's not even nonstandard yet
 27 2015-02-04 00:50:43 <sipa> but it's trivial to implement
 28 2015-02-04 00:51:12 <sipa> if (sig == 0) { sigcheck_failure; } else if (sigcheck(sig)) { ok; } else { script_failure; }
 29 2015-02-04 00:53:26 <rusty> sipa: I wonder if there's some script which would want to test multiple signatures manually... would be kind of dumb, rather than checking pubkeys.
 30 2015-02-04 00:53:40 <sipa> ?
 31 2015-02-04 00:55:43 <jtimon> btw cfields #5747 probably interests you for the consensus code movements
 32 2015-02-04 01:20:03 <morcos> sipa: i'm wondering if not allowing non-0 incorect sigs is limiting, or is it always the case that you can malleate the transaction to replace an incorrect signature with a 0 to make it so you're in sigcheck_failure and not script_failure
 33 2015-02-04 01:20:43 <sipa> morcos: unless you have a signature in the scriptpubkey or redeemscript, yes
 34 2015-02-04 01:22:07 <morcos> right, but if you are putting a signature in the pubkey or redeemscript that might be invalid, then its defnitely invalid right, and so you might as well have made it a 0 in the first place
 35 2015-02-04 01:22:59 <morcos> or actually there is no way to put a valid signautre in one of those
 36 2015-02-04 01:24:49 <sipa> actually, there is
 37 2015-02-04 01:25:07 <sipa> odd as it may seem, it's actually possible
 38 2015-02-04 01:25:45 <sipa> if a script contains the signature vector being validated, it is removed (search-replaced by nothing) before computing the sighash
 39 2015-02-04 01:28:13 <rgenito> how can i turn the private key into the wallet import format key?
 40 2015-02-04 01:28:22 <morcos> by redeem script, you aren't referring to what's hashed to be the p2sh output in the first tx?
 41 2015-02-04 01:28:52 <sipa> morcos: yes i am, and i *believe* it's impossible to create a redeemscript with a valid signature in it
 42 2015-02-04 01:29:18 <sipa> morcos: but for non-P2SH, i believe petertodd has created valid self-signing transactions
 43 2015-02-04 01:29:35 <sipa> cfields: want to have a look at secp256k1 #208? it should remove all non-constant globals
 44 2015-02-04 01:30:12 <cfields> jtimon: will have a look, thanks
 45 2015-02-04 01:30:14 <cfields> sipa: woohoo!
 46 2015-02-04 01:30:30 <rgenito> is there a way from the bitcoin core client to dump a private key to WIF?
 47 2015-02-04 01:30:39 <sipa> rgenito: dumpprivkey RPC
 48 2015-02-04 01:30:52 <morcos> sipa: ok i'll have to google for that later .. got to run.  thanks.
 49 2015-02-04 01:30:54 <cfields> sipa: i started on that at one point but ended up overwhelmed at the amount of changes necessary. thanks for doing that!
 50 2015-02-04 01:30:59 <rgenito> sipa, i did this, but the private key starts with "L"
 51 2015-02-04 01:31:06 <sipa> rgenito: yup, it's WIF
 52 2015-02-04 01:31:17 <rgenito> and when i try to import it into another wallet (armory), armory says that it's not valid for ECDSA et
 53 2015-02-04 01:31:19 <rgenito> etc*
 54 2015-02-04 01:31:30 <sipa> WIF for compressed-pubkey privkeys
 55 2015-02-04 01:31:42 <sipa> armory doesn't support compressed keys yet?
 56 2015-02-04 01:31:47 <sipa> still?
 57 2015-02-04 01:32:09 <sipa> they were introduced with bitcoin core 0.6
 58 2015-02-04 01:32:21 <rgenito> sooo, is there a way with the core client to change the format of the dumped private key? =[
 59 2015-02-04 01:32:22 <sipa> 3 years ago
 60 2015-02-04 01:32:26 <rgenito> i guess i can use bitaddress.org
 61 2015-02-04 01:32:26 <sipa> rgenito: no
 62 2015-02-04 01:32:31 <sipa> no
 63 2015-02-04 01:32:34 <sipa> it won't work
 64 2015-02-04 01:32:48 <sipa> armory does not support the keys that modern bitcoin core uses
 65 2015-02-04 01:32:59 <sipa> converting them to non-compressed won't work, as the corresponding address changes
 66 2015-02-04 01:33:08 <sipa> for all intents and purposes, they are different keys
 67 2015-02-04 01:33:33 <rgenito> well then
 68 2015-02-04 01:33:39 <rgenito> i guess my next question belongs in the armory channel
 69 2015-02-04 01:33:44 <Luke-Jr> wtf, still?
 70 2015-02-04 01:33:45 <rgenito> "Why on earth don't you guys support this????"
 71 2015-02-04 01:33:46 <sipa> go complain to armory if you need that feature :)
 72 2015-02-04 01:33:58 <sipa> i thought armory was working on support that... years ago
 73 2015-02-04 01:34:01 <rgenito> lol ya
 74 2015-02-04 01:34:01 <sipa> but i haven't followd up
 75 2015-02-04 01:34:10 <rgenito> i mean, didn't they get ~$600k funding? o.O
 76 2015-02-04 02:11:11 <sdaftuar> sipa: no worries :) do you happen to have a link where i can learn more about petertodd's self-signing transactions?  my searches for it are turning up empty
 77 2015-02-04 02:36:38 <rgenito> Luke-Jr, sipa ok so from that previous mentioning of Armory...
 78 2015-02-04 02:36:45 <rgenito> i'm pretty convinced Electrum is a good option ;x
 79 2015-02-04 02:36:51 <rgenito> (other than bitcoin core)
 80 2015-02-04 02:37:19 <Luke-Jr> rgenito: this is #bitcoin material
 81 2015-02-04 02:37:29 <rgenito> mah bad mah bad
 82 2015-02-04 02:37:32 <rgenito> that's right
 83 2015-02-04 03:09:48 <cfields> sipa: it's not obvious to me why there's "secp256k1_context_create(int flags)" as well as secp256k1_context_initialize_*. I would expect the context_create to initialize. Is that just a way of allowing for the context to be initially created with no initialization?
 84 2015-02-04 04:00:48 <Luke-Jr> cfields: I would imagine/guess it's so you can have the context on the stack (without seeing the code)
 85 2015-02-04 04:14:44 <rgenito> i'm having a hard time finding this in the bitcoin wiki... but how is it that test net coins stay worthless?
 86 2015-02-04 04:17:08 <rusty> rgenito: addresses are completely separate, so they can't be used on main net.  Separate blockchain, thus separate coin.  OR was your question more meta?
 87 2015-02-04 04:17:21 <rgenito> probably more meta
 88 2015-02-04 04:17:33 <rgenito> i see that in testnet2, people were using the coins for value, and then testnet3 "solved" this some how
 89 2015-02-04 04:17:44 <rusty> rgenito: yeah, by throwing away testnet2 :)
 90 2015-02-04 04:18:20 <rusty> rgenito: test net also has a nicely exploitable difficulty reset heuristic.
 91 2015-02-04 04:18:25 <rgenito> soo...it's not valuable only in the way that it's separate from the bitcoin network itself, and most bitcoin wallets don't use the test net as default? =|
 92 2015-02-04 04:18:41 <rgenito> rusty, thatttts what i'm lookin for
 93 2015-02-04 04:18:57 <rgenito> i saw that if a block isn't solved in "20 minutes", the difficulty is reset
 94 2015-02-04 04:18:59 <rusty> rgenito: see here: http://tpfaucet.appspot.com/ Has some commentry on "worth" of testcoins
 95 2015-02-04 04:19:39 <rgenito> lol is that donation a test net address or a regular net address? ;D
 96 2015-02-04 04:20:28 <rgenito> i see, so the test net is easily erased
 97 2015-02-04 04:20:49 <rgenito> i kinda want to go to the tn faucet that has the most coins paid out lol
 98 2015-02-04 04:49:31 <Luke-Jr> rgenito: how many you need? I have like 10k
 99 2015-02-04 05:01:18 <rgenito> Luke-Jr, awesome lol
100 2015-02-04 05:02:00 <rgenito> how about 10 ?
101 2015-02-04 05:03:35 <Luke-Jr> addr?
102 2015-02-04 05:05:51 <rgenito> mmSP2cfMSYQ6Sfw5JXcfLxFWAHvufJevg9
103 2015-02-04 05:34:21 <sipa> cfields: so the purpose is to support choosing the size of the precomputed tables, where the flags just give you defaukts, while the initialize function support customizatiins
104 2015-02-04 05:34:47 <sipa> cfields: plus there will be a "add blinding seed", which can modify a context
105 2015-02-04 05:36:43 <cfields> sipa: ok. It's a bit confusing to have the redundant functionality, but i see its usefulness
106 2015-02-04 05:38:10 <sipa> i can remove it from now, and add it ack when it is useful
107 2015-02-04 05:38:15 <sipa> but meh
108 2015-02-04 05:39:22 <cfields> sipa: nah, i just wanted to understand. that makes sense.
109 2015-02-04 07:26:53 <fanquake> ;;blocks
110 2015-02-04 07:26:54 <gribble> 341887
111 2015-02-04 07:50:09 <Luke-Jr> wumpus: status on rc4?
112 2015-02-04 07:51:47 <gmaxwell> Luke-Jr: it's blocked on BIP66 please don't nag wumpus.
113 2015-02-04 07:52:18 <Luke-Jr> not trying to nag, just know status. :x
114 2015-02-04 07:56:01 <wumpus> it's all up to sipa
115 2015-02-04 07:56:47 <wumpus> catching up with my mail, though, I think he retracted the amandment to BIP66, but I'm not sure he still wants to propose something else
116 2015-02-04 07:57:57 <wumpus> given that, and that no one pokes any holes in BIP66, we should just continue with the 0.10 rc cycle and tag rc4 today
117 2015-02-04 07:58:16 <Luke-Jr> the empty-byte-vector stuff is already in BIP66/0.10, right?
118 2015-02-04 07:58:36 <wumpus> yes it should be
119 2015-02-04 07:59:05 <Luke-Jr> found it
120 2015-02-04 08:00:37 <gmaxwell> wumpus: I think he wants to proposed a simple IsStandard rule seperate from BIP66 for now.
121 2015-02-04 08:00:55 <gmaxwell> he may be back online in another half hour or so.
122 2015-02-04 08:00:55 <sipa> yeah, i'll write something for 0.11
123 2015-02-04 08:01:03 <sipa> lol
124 2015-02-04 08:01:48 <gmaxwell> very short half hour.
125 2015-02-04 08:02:00 <sipa> a 0-second half hour
126 2015-02-04 08:02:04 <Luke-Jr> ☺
127 2015-02-04 08:02:06 <wumpus> hehe
128 2015-02-04 08:02:40 <Luke-Jr> sipa: do you mean the IsStandard rule waits for 0.11, or promotion of it to softfork?
129 2015-02-04 08:02:52 <sipa> the isstandard rule itself
130 2015-02-04 08:03:08 <sipa> it may be controversial, and i don't want to burden 0.10 further
131 2015-02-04 08:03:09 <wumpus> okay, great
132 2015-02-04 08:03:19 <Luke-Jr> fair enough
133 2015-02-04 08:03:21 <wumpus> indeed
134 2015-02-04 08:04:20 <wumpus> it's worth doing 0.10 right, if there are critical problems with the current implementation/proposal they should be fixed before release, but anything remotely controversial can indeed wait for 0.11
135 2015-02-04 08:04:31 <gmaxwell> petertodd suggested it, it's a good idea, though it might break some data-embedding thing(s) thus making it controversial.
136 2015-02-04 08:07:29 <sipa> gmaxwell: actually... no
137 2015-02-04 08:07:38 <sipa> it's inherently malleable
138 2015-02-04 08:07:46 <sipa> so you can't use it for data storage
139 2015-02-04 08:08:08 <sipa> all invalid signatures are already functionally identical with eachother
140 2015-02-04 08:08:49 <Luke-Jr> doesn't mean people aren't using it :p
141 2015-02-04 08:09:09 <gmaxwell> sipa: I take your bet and raise you a OP_SIZE.
142 2015-02-04 08:09:31 <sipa> ha
143 2015-02-04 08:09:37 <gmaxwell> but indeed, it wouldn't make a good data storage thing; thus the 'might' I guess.
144 2015-02-04 08:10:37 <wumpus> if it is not used as a data-embedding thing right now, that luckily makes it less controversial, not so many people worry about might-have-beens
145 2015-02-04 08:12:45 <gmaxwell> AFAIK it's not. though one of the somewhat irritating things about 0.10 is that it greatly relaxes IsStandard such that things may happen which currently do not. (though even currently you could try to store data in signatures, since IsStandard doesn't say that much relative to this.)