1 2017-12-27 00:03:15 <eck> very insightful, thanks for letting us know
  2 2017-12-27 00:09:05 <spectra> |shame on the devs for selling out
  3 2017-12-27 00:09:16 <spectra> |why don't we just increase the block size?
  4 2017-12-27 00:17:39 <eck> this topic is more appropriate for #bitcoin
  5 2017-12-27 00:29:01 <xexe> can any set of rules at all governing the txes cherry-picking from the mempool be introduced as protocol for miners?
  6 2017-12-27 00:30:35 <Dagronmaster> "cherry-picking" transactions is a feature, not a bug
  7 2017-12-27 00:31:07 <xexe> who defines the cherry-picjing rules at present?
  8 2017-12-27 00:31:18 <eck> the person who mines the block
  9 2017-12-27 00:31:56 <xexe> that's crazy, shouldn't they have just the validating funciton and not governing?
 10 2017-12-27 00:33:11 <Dagronmaster> who's governing?
 11 2017-12-27 00:33:29 <xexe> what if we figure out some probability distribution weight function let's say add a bit of randomization here. how can this be enforced for miners then?
 12 2017-12-27 00:34:22 <eck> who would enforce it?
 13 2017-12-27 00:34:48 <Dagronmaster> from each miner according to his ability, to each transaction creator according to his need
 14 2017-12-27 00:35:05 <eck> transactions in the mempool are not globally consistent anwyay, so it's pointless to try to enforce
 15 2017-12-27 00:35:49 <xexe> the community, peeps who actually use the network, devs etc. it's about the governance model isn't it
 16 2017-12-27 00:36:02 <eck> so what would you propose they do?
 17 2017-12-27 00:36:37 <eck> we can have a twitter poll to ask people what transactions should be included in the next block but i don't think that's going to help
 18 2017-12-27 00:37:44 <xexe> well they whould be fairly consistent, or tend to be at least, nevermind the propagation latency and all that
 19 2017-12-27 00:37:59 <eck> in the common case, yes
 20 2017-12-27 00:38:55 <eck> there are legitimate reasons a miner might want to do something out of the ordinary though
 21 2017-12-27 00:39:13 <eck> bitcoin is designed to give miners the economic incentives to do the Right Thing, which is really the best you can do in a distributed, trustless system
 22 2017-12-27 00:39:23 <eck> it might not work 100% of the time but it's pretty close
 23 2017-12-27 00:39:33 <xexe> the q is how this or any other model be introduced tyo miners. what sowtware code do they use? core or their own?
 24 2017-12-27 00:40:12 <eck> most of them run a bitcoin core node on the edge of their network, but in some cases they might modify the code
 25 2017-12-27 00:41:52 <eck> here's an example of a legitimate reason you might want to do something unusual as a miner. let's say you're mining, and for some reason you have a lot of "dust" utxos (e.g. because you are also an exchange). you might want to mine a block to coalesce your dust utxo outputs with 0 tx fees, and you probably wouldn't even bother broadcasting those txs to the network until you actually mine a block with
 26 2017-12-27 00:41:54 <eck> them.
 27 2017-12-27 00:42:04 <xexe> i think they have more than enough economic incentinve at the moment with 4+ in each block
 28 2017-12-27 00:42:43 <eck> the example i just gave is not even hypothetical, it does/has happened on mainnet
 29 2017-12-27 00:44:53 <xexe> it's just that economic incentive alone has never been the best governing model to do the Right Thing in this life afaik
 30 2017-12-27 00:45:14 <eck> maybe not, but that's how distributed systems work
 31 2017-12-27 00:46:04 <xexe> we are talking about chaos systems, where probalbility laws rule and distribution fucntions and strange attractors and all that
 32 2017-12-27 00:46:19 <eck> how are strange attractors and chaos systems at all related?
 33 2017-12-27 00:46:41 <xexe> and at the oment i do not see any quantum probabalistic features employed in this cherrypicking
 34 2017-12-27 00:47:02 <eck> you're right, you can implement it with a single for lop
 35 2017-12-27 00:47:43 <eck> consider this though, let's say there are some bad actors in the system. that should be ok, as long as they don't have excessive hashing power.
 36 2017-12-27 00:47:51 <eck> which is why mining decntralization is important
 37 2017-12-27 00:48:09 <eck> and decentralization of the network in general
 38 2017-12-27 00:49:55 <xexe> you mean ddosing the meemppol with dust? is this shear fee amount is really the only option to mitigate that sort of attack out there?
 39 2017-12-27 00:50:52 <eck> for the people creating the dust transactions, or the people mining the blocks
 40 2017-12-27 00:50:54 <eck> ?
 41 2017-12-27 00:58:19 <xexe> miners have had too much power here, and that should better be limited for them. they should basically run on 'donations' maybe not quite but something like that
 42 2017-12-27 01:11:06 <xexe> the same with these powers that be, no matter how much it's never enough for them. they simply do not have such self-limiting function in their psyche. they are there in society because they have some mean function but that's all. they have never been the most wise or pure (and they act as if they are) in fact they are the most vile & vicious minority of the whole hive. they insatiable hunger for power &
 43 2017-12-27 01:11:08 <xexe> control is going to ruin evrything. that's why the hive should figure out some way to prevent them from seizing this absolute power time & again in history..
 44 2017-12-27 01:36:25 <echeveria> xexe: you simply can't attempt to force rules over transaction selection.
 45 2017-12-27 02:14:53 <xexe> yes enforcement isn't the dharmic way or method to achieve anything worthwhile, distributed consensus is..
 46 2017-12-27 02:15:46 <echeveria> yes, in bitcoin that happens after transactions are confirmed.
 47 2017-12-27 02:15:51 <xexe> i'm telling you why i'm trying to do. not how i'm trying to do..
 48 2017-12-27 02:16:07 <echeveria> I'm telling you, no matter how noble, you can't have this.
 49 2017-12-27 02:23:41 <xexe> i'll think about that but if the hivemind isn't going to figure out that then perhaps we will forever be at the mercy of miners, which isn't much sustainable state of affairs in the long run..
 50 2017-12-27 02:24:41 <vinnix> I was looking into "bitcoin/src/leveldb/db/db_impl.cc" function DBImpl::Get
 51 2017-12-27 02:25:42 <vinnix> there is a interesting part "if (have_stat_update && current->UpdateStats(stats)) { MaybeScheduleCompaction() }
 52 2017-12-27 02:27:51 <vinnix> since I got the mem leak report from valgrind, I am diging more into the code :)
 53 2017-12-27 02:28:47 <vinnix> from the user perspective I'm observing it during '-reindex'
 54 2017-12-27 02:43:47 <echeveria> xexe: you can wax lyrical about this all you want, but the simple reality is that miners will choose whatever is profitable for them. trying to make social rules around transaction selection is worse than useless.
 55 2017-12-27 02:49:45 <xexe> can you still afford to use the fintech in question? because i can't anymore; which isn't much egalitarian status quo..
 56 2017-12-27 02:51:49 <Dagronmaster> to look for egalitarian qualities in anything remotely libertarian is a recipe for disappointment
 57 2017-12-27 02:56:25 <xexe> yes heart-breaking it is, as ususal. but wax candles & noble fir is so much holiday..
 58 2017-12-27 03:29:30 <xexe> not even mentioning lack of deflationary liquidity this whole enterprise resembles more and more some enterprise for Argonauts instead of sustainable ecosystem; but perhaps it was meant to be has always been so from the start so at the end of the day it's al-right..
 59 2017-12-27 04:32:50 <xiedeacc> what's nChainWork for ?
 60 2017-12-27 04:33:27 <xiedeacc> in class CBlockIndex
 61 2017-12-27 05:03:00 <phantomcircuit> xiedeacc, it's the inverse of difficulty
 62 2017-12-27 05:03:11 <phantomcircuit> so you can easily calculate the total work done in a long chain
 63 2017-12-27 05:16:18 <DSidH> I realize that we can get two public keys from each signature. How did arubi say we can get 4 or even 8?
 64 2017-12-27 05:16:53 <DSidH> And I am not able to find any documentation for encoding signatures with recovery.. except maybe this one: https://godoc.org/github.com/ethereum/go-ethereum/crypto/secp256k1#Sign
 65 2017-12-27 05:17:28 <DSidH> can anyone guide me on how to encode a recoverable signature?
 66 2017-12-27 05:18:00 <xiedeacc> ok, thanks~
 67 2017-12-27 05:37:48 <echeveria> DSidH: read the comments in the libsecp256k1 code.
 68 2017-12-27 05:53:26 <DSidH> echeveria: I did Google for "libsecp256k1 code". Too much info. Can you please point me to the right github link?
 69 2017-12-27 05:55:49 <DSidH> one link is this: https://bitcointalk.org/index.php?topic=6430.msg94738#msg94738
 70 2017-12-27 05:57:50 <DSidH> but it does not give too much info about encoding
 71 2017-12-27 05:58:37 <DSidH> [10:46] <DSidH> I realize that we can get two public keys from each signature. How did arubi say we can get 4 or even 8?
 72 2017-12-27 05:58:58 <DSidH> actually its 4 (2 x values and 2 y values for each x).. but I don't get how it can be 9
 73 2017-12-27 05:59:01 <DSidH> 8*
 74 2017-12-27 07:03:35 <echeveria> DSidH: it’s in the “bitcoin” group on github.
 75 2017-12-27 08:14:24 <ujjwalt> Hi guys
 76 2017-12-27 08:14:37 <Randolf> Hello ujjwalt.
 77 2017-12-27 08:14:42 <ujjwalt> Anyone here can help me understand how base58 in bitcoin works at the implmentation level
 78 2017-12-27 08:14:50 <ujjwalt> Hi Randolf
 79 2017-12-27 08:15:14 <Randolf> Base58 is merely a representation of a number.
 80 2017-12-27 08:15:25 <ujjwalt> I specially can’t seem to understand what this line does - `std::vector<unsigned char>::iterator it = b58.begin() + (size - length);`
 81 2017-12-27 08:15:28 <Randolf> Just like Base16 is (hexadecimal).
 82 2017-12-27 08:15:48 <ujjwalt> Right. How does the bitcoin version work?
 83 2017-12-27 08:16:04 <ujjwalt> Not strong at CPP so can’t seem to understand some things
 84 2017-12-27 08:16:15 <Randolf> Base58 is a standard.  There's no "Bitcoin version" that differs from any other use of Base58.
 85 2017-12-27 08:16:16 <ujjwalt> Like this: `int size = (pend - pbegin) * 138 / 100 + 1; // log(256) / log(58), rounded up.`
 86 2017-12-27 08:17:11 <ujjwalt> first we’re counting the leading zeroes in the data buffer
 87 2017-12-27 08:17:16 <ujjwalt> when encoding
 88 2017-12-27 08:17:56 <Randolf> A zero is encoded as a 1.
 89 2017-12-27 08:18:01 <ujjwalt> ok
 90 2017-12-27 08:18:20 <Randolf> ujjwalt:  Maybe this document will help:  https://en.bitcoin.it/wiki/Base58Check_encoding
 91 2017-12-27 08:18:53 <ujjwalt> I’ve gone through it
 92 2017-12-27 08:19:03 <ujjwalt> just clarify two three things for me in the code
 93 2017-12-27 08:19:11 <ujjwalt> / Apply "b58 = b58 * 256 + ch".
 94 2017-12-27 08:19:17 <ujjwalt> what are we basically doing here
 95 2017-12-27 08:19:24 <ujjwalt> and why are we going over b58 in reverse?
 96 2017-12-27 08:19:39 <ujjwalt> and this line: std::vector<unsigned char>::iterator it = b58.begin() + (size - length);
 97 2017-12-27 08:19:52 <ujjwalt> Sorry how am I supposed to paste code here?
 98 2017-12-27 08:20:05 <ujjwalt> Is there a convention we follow on this room?
 99 2017-12-27 08:20:25 <arubi> it's fine to paste just a couple lines
100 2017-12-27 08:20:36 <Randolf> If it's only a few lines, then IRC chat is fine,but for longer code use a service like Pastebin.ca.
101 2017-12-27 08:20:52 <ujjwalt> got it
102 2017-12-27 08:23:57 <ujjwalt> why do we use a revese iterator? Any idea?
103 2017-12-27 08:28:27 <arubi> DSidH, it can be that 4 pubkeys can be recovered from a signature and message if the 'r' value in the sig is smaller than (p - n) (p is the prime and n is the curve order), because we take the original R's point X coordinate (mod n), so when we have such an r value, we can check if it's a valid X coordinate, and also check if (r + n) is a valid coordinate, and recover 2 different pubkeys for each option
104 2017-12-27 08:28:55 <arubi> ujjwalt, I'm not too sure about the c++, but wouldn't you do any base conversion like that?
105 2017-12-27 08:30:53 <DSidH> arubi: so we have r, r+n and the corresponding y's?
106 2017-12-27 08:31:05 <DSidH> (I mean the key recovered from r and r+n)
107 2017-12-27 08:31:59 <arubi> the Y coordinate inclusions in the pubkey hash or not is what makes for two addresses for each recovered pubkey
108 2017-12-27 08:32:54 <DSidH> ok.. http://www.secg.org/sec1-v2.pdf I am referring this section 4.3 to implement key recovery
109 2017-12-27 08:33:58 <DSidH> where the cofactor is 1 as in bitcoin
110 2017-12-27 08:34:24 <arubi> so I didn't understand the question.  the pubkey being compressed or not matters for bitcoin specifically.  that document doesn't care about it
111 2017-12-27 08:37:35 <DSidH> nvm the question, I was thinking that we find two different x coordinates first for possible public keys. Then each x has two possible y coordinates, which gives us 4 points
112 2017-12-27 08:38:44 <DSidH> similar to we find the y of a sig.. but this seems to be wrong
113 2017-12-27 08:39:22 <arubi> yea the Y values of the recovered keys are unrelated between them
114 2017-12-27 08:39:34 <arubi> or maybe better, are not +-Y :)
115 2017-12-27 09:26:39 <DSidH> arubi: I am finding that most signatures have only 2 keys.. is this expected?
116 2017-12-27 09:27:03 <arubi> here: https://gist.github.com/fivepiece/4cf7a9d1f3efc56f47835d168f3696f6
117 2017-12-27 09:27:55 <arubi> first one should recover 4 keys to 8 addresses, second one recovers only the "small" R_x pubkeys, third one should recover only the "big" R_x keys
118 2017-12-27 09:28:29 <DSidH> R = 68053886848776677441133659300543143116349777749036069675459047078098205334997 S = 40438720191521726420796838536941300170400936095250279510361216891756193879060 Hash as Int = 20329878786436204988385760252021328656300425018755239228739303522659023427620 PK1 105932108814481395905759851533798966534115425465770952541697246848027772578198,80011604461019602521402058374560558590524450437601070093989309960612944029061 PK2 10730358229073
119 2017-12-27 09:28:31 <DSidH> example
120 2017-12-27 09:29:05 <arubi> err, s/first/third/ and third/first.  seems like the gist is backwards
121 2017-12-27 09:29:29 <DSidH> 1 min checking
122 2017-12-27 09:53:08 <DSidH> arubi: ah I get it now. we get max 4 keys in terms of points and then 4 more considering uncompressed and compressed!
123 2017-12-27 09:55:19 <arubi> yep, that's it
124 2017-12-27 10:48:43 <DSidH> arubi: thanks for the test vectors. I am still confused as to how to decide which public key to associate the signature with.
125 2017-12-27 10:48:50 <DSidH> all of them return true
126 2017-12-27 10:58:53 <arubi> yes, the first byte in the 65 byte recoverable signature tells you which to choose.  that's the 3x8 table I posted yesterday.  if you base64 decode the signatures, you'll see it
127 2017-12-27 11:12:36 <DSidH> ok so there is some canonical ordering.. first do compressed using r then r + n and then get 4 points, then do same for uncompressed
128 2017-12-27 11:19:41 <arubi> also the even R's recovered key is returned first
129 2017-12-27 11:38:55 <DSidH> arubi: https://gist.github.com/fivepiece/4b5a026c6f74a47162fe1198e19838ee this one :)
130 2017-12-27 11:39:18 <DSidH> so I have to strip the first byte of the signature
131 2017-12-27 11:41:02 <arubi> yes those signatures are [ recid byte ][ 32 bytes r ][ 32 bytes s]
132 2017-12-27 11:46:16 <DSidH> arubi: is the even-odd guaranteed? I could not see it directly, like can we not have (y_even, x < r), (y_even, x < r)
133 2017-12-27 11:47:22 <DSidH> (r = n)
134 2017-12-27 11:47:47 <arubi> I'm talking about R's y being even or not
135 2017-12-27 11:48:29 <DSidH> oh ...
136 2017-12-27 11:48:37 <arubi> you take 'r', check if it's a valid x, find it's two y values and recover right, so the pubkey that gets recovered by the r_x,r_y where y is.. yea you get it :)
137 2017-12-27 11:49:20 <echeveria> more ideally we should just have a consensus rule that says y must always be even, then the pubkey becomes 16 bytes.
138 2017-12-27 11:49:31 <DSidH> yup I was confusing with the xs and ys of the pub key
139 2017-12-27 11:49:38 <echeveria> too late for that though.
140 2017-12-27 11:50:09 <arubi> you mean 32 bytes?
141 2017-12-27 11:50:44 <echeveria> er, yeah.
142 2017-12-27 12:01:58 <DSidH> or even better public key should just be x coordinate
143 2017-12-27 12:02:22 <DSidH> and yes even
144 2017-12-27 12:02:38 <DSidH> but can we not ignore the y when hashing?
145 2017-12-27 12:03:13 <DSidH> so then question of "even" will not even arise
146 2017-12-27 12:06:48 <arubi> in bitcoin the public keys are compressed
147 2017-12-27 12:07:18 <arubi> so it's 33 bytes.  only very old wallets and services might use an uncompressed pubkey these days
148 2017-12-27 12:07:30 <DSidH> yes but we just assume public keys are only x coordinates and when we need to verify, we always take the even y
149 2017-12-27 12:07:42 <DSidH> but while computing Hash(pubKey) we only use x
150 2017-12-27 12:08:08 <arubi> but what if your pubkey actually has an odd y coordinate?
151 2017-12-27 12:08:21 <DSidH> its a wrong key
152 2017-12-27 12:08:37 <arubi> you mean when you generate the private key itself, you also tweak it to always make an even point?
153 2017-12-27 12:08:43 <arubi> even y that is
154 2017-12-27 12:08:51 <DSidH> yup we always assume that odd y is invalid
155 2017-12-27 12:09:12 <arubi> well it at least cuts the private key range by half :)
156 2017-12-27 12:09:19 <DSidH> if Y is odd then -Y will be even
157 2017-12-27 12:09:42 <arubi> sure, but then you're losing security bits I think?  not sure
158 2017-12-27 12:09:56 <DSidH> hmm no the private key space is still same
159 2017-12-27 12:10:06 <arubi> how so?  you also have to negate the private key
160 2017-12-27 12:10:22 <arubi> if Y odd is invalid, and x makes that point, then it's an invalid private key
161 2017-12-27 12:10:26 <arubi> but -x will be the valid one
162 2017-12-27 12:10:43 <DSidH> hmm maybe Im confused. We generate x and then compute Y = xG
163 2017-12-27 12:10:46 <arubi> and because you're always reducing mod n, then half the range is always flipped
164 2017-12-27 12:10:52 <arubi> no no
165 2017-12-27 12:10:52 <DSidH> and if Y is even (i.e., Y_y is even)
166 2017-12-27 12:10:56 <arubi> xG = (X,Y)
167 2017-12-27 12:10:58 <DSidH> then we set Y = -Y
168 2017-12-27 12:11:12 <arubi> better, normally the private key is 'd'
169 2017-12-27 12:11:15 <DSidH> no capitals are curve points in my notation :)
170 2017-12-27 12:11:17 <arubi> so dG = (x,y)
171 2017-12-27 12:11:34 <arubi> oh, yes, so xG = Y and -xG = -Y
172 2017-12-27 12:11:50 <DSidH> dG = (x, y) and -dG = (x, -y)
173 2017-12-27 12:11:54 <arubi> yes
174 2017-12-27 12:12:32 <arubi> so if dG = even y value, then -dG = odd y value
175 2017-12-27 12:12:47 <arubi> makes -d % n an invalid key, which is half the range
176 2017-12-27 12:13:16 <DSidH> so we keep private key d and keep pub key either -dG or dG
177 2017-12-27 12:13:19 <DSidH> depending on which is even
178 2017-12-27 12:14:05 <arubi> how would that work?  someone with the key d and someone else with the key -d will have the same pubkey?
179 2017-12-27 12:14:06 <DSidH> as far as I see this does not reduce private key space, since every d will generate a valid pub key
180 2017-12-27 12:14:33 <DSidH> then that one with -d and d will have lot more to worry about then pub key collision :)
181 2017-12-27 12:15:14 <DSidH> two people generating the same d wont happen i
182 2017-12-27 12:15:15 <arubi> their first worry would be this new consensus rule
183 2017-12-27 12:15:35 <arubi> since it's more strict than the same d.  it adds -d too
184 2017-12-27 12:16:02 <arubi> I don't see how that's not just throwing away one bit
185 2017-12-27 12:16:54 <arubi> if we say all pubkeys are 32 bytes + 1 bit, then you say lose that one bit
186 2017-12-27 12:17:26 <DSidH> yes but the private key space is still 32 bytes so security is only 32 bytes
187 2017-12-27 12:18:21 <arubi> it's essentially the same as half the range, if you make people sign with their -d when they have d
188 2017-12-27 12:18:38 <arubi> since a signature from d will not be valid if the point dG is odd
189 2017-12-27 12:19:41 <DSidH> it will be valid under pub key -(dG)
190 2017-12-27 12:19:57 <arubi> it won't if you'll use your normal d to sign
191 2017-12-27 12:20:12 <arubi> you'll have to use -d if d gives you an odd point
192 2017-12-27 12:20:39 <DSidH> hmm maybe not in current scenario but if we only keep hash(x coordinate of pub key), it will be
193 2017-12-27 12:20:57 <arubi> it still won't be
194 2017-12-27 12:21:22 <DSidH> sorry I made a typo
195 2017-12-27 12:21:30 <DSidH> signer should sign it using -d
196 2017-12-27 12:21:44 <arubi> then they're effectively choosing from half the range..
197 2017-12-27 12:21:55 <arubi> it doesn't matter that they generated d if they end up signing with -d
198 2017-12-27 12:23:06 <Eric_Fly> anybody is here? I need help
199 2017-12-27 12:24:08 <DSidH> hmmm in the malleability attack, didn;t the signature verify under both dG and -(dG) ?
200 2017-12-27 12:24:20 <arubi> it's s and -s
201 2017-12-27 12:24:40 <arubi> it's R's odd\even that gets flipped in that case
202 2017-12-27 12:24:56 <Eric_Fly> what's the segwit address?
203 2017-12-27 12:25:03 <DSidH> ok... I see but I still don't see how removing one byte can reduce security by half
204 2017-12-27 12:25:07 <DSidH> something is wrong in the reasoning
205 2017-12-27 12:25:12 <echeveria> DSidH: remember that's not the only cause of malleability.
206 2017-12-27 12:25:58 <DSidH> instead of 256 bits we may get 255 bits
207 2017-12-27 12:26:04 <DSidH> half of them being lost as u said
208 2017-12-27 12:26:33 <arubi> really the security for secp256k1 is 128 bits
209 2017-12-27 12:26:39 <echeveria> yup.
210 2017-12-27 12:27:45 <DSidH> If I am able to guess -d then I am able to guess private keys of all two pub keys.. so security should not be lost
211 2017-12-27 12:28:01 <Eric_Fly> I saw segwit address on blockchain like bc1..... but i decoderawtransaction like multisigaddress why?
212 2017-12-27 12:28:16 <echeveria> Eric_Fly: that's bip173.
213 2017-12-27 12:28:23 <echeveria> bech32.
214 2017-12-27 12:28:43 <arubi> it's not about guessing.  the attacks are much more involved than some brute force search
215 2017-12-27 12:28:51 <Eric_Fly> I decode to bip173?
216 2017-12-27 12:29:21 <arubi> I don't know for certain, I'm just worried making half the people negate their private keys for signing will make the attacks easier
217 2017-12-27 12:29:21 <DSidH> in fact if I recall (with a bit of hunch) that security is only 128 bits because we only need to search half keyspace
218 2017-12-27 12:29:34 <DSidH> in the generic group model
219 2017-12-27 12:29:38 <arubi> I don't think that's the reason
220 2017-12-27 12:30:21 <DSidH> sorry its square root of the keyspace
221 2017-12-27 12:32:11 <arubi> I think it's related to the size of the largest factor in (n-1)
222 2017-12-27 12:32:23 <arubi> I'm really not sure
223 2017-12-27 12:33:19 <DSidH> in the generic group model, it takes approx sqrt(n) tries to find dlog.. you're right that its not related to the issue we are discussing
224 2017-12-27 12:33:21 <arubi> maybe not
225 2017-12-27 12:34:24 <Eric_Fly> thank u for echeveria~i try
226 2017-12-27 12:36:42 <DSidH> (where n is our prime order of G)
227 2017-12-27 12:38:23 <arubi> well, whether it's reducing security or not, it's still a lot of overhead just to save what's really one byte :)
228 2017-12-27 12:41:49 <DSidH> ecc is always confusing. I'll go back to key recovery code and paste some test vectors
229 2017-12-27 12:42:17 <arubi> cool
230 2017-12-27 12:52:56 <Eric_Fly> how to deocde scriptPubKey's hex to Bech32 address
231 2017-12-27 12:57:40 <DSidH> arubi: if r or s are less than 32 bytes do we pad with 0s?
232 2017-12-27 12:57:45 <DSidH> in the key recovery encoding
233 2017-12-27 12:58:06 <arubi> right
234 2017-12-27 12:58:13 <arubi> left pad
235 2017-12-27 12:58:21 <DSidH> kk thx
236 2017-12-27 13:33:14 <xiedeacc> what's CBlockIndex* pskip; for?
237 2017-12-27 14:58:23 <Dagronmaster> xiedeacc:  It's a pointer to a predecessor block of this block
238 2017-12-27 14:58:57 <Dagronmaster> a predecessor that's farther up the chain than the last one
239 2017-12-27 15:00:09 <xiedeacc> thanks
240 2017-12-27 15:00:14 <xiedeacc> after google
241 2017-12-27 15:01:06 <xiedeacc> it like a binary tree, and predecessor is father(grand... node
242 2017-12-27 15:01:17 <xiedeacc> just for speedup lookup
243 2017-12-27 15:28:26 <IR> Hi, when creating a transaction, do we use a different scriptSig for each input?
244 2017-12-27 19:06:06 <DSidH> arubi: need some help
245 2017-12-27 19:06:07 <DSidH> https://gist.github.com/scalahub/96f31c6656802b5547a28a03d6d22cff
246 2017-12-27 19:06:44 <DSidH> everything done .. recovery works.. except that my signatures don't match with test vectors. Both sigs are valid (at least with my code)
247 2017-12-27 19:06:57 <DSidH> can you let me know which one are generated  by you
248 2017-12-27 19:07:37 <DSidH> test vectors are from a SO post
249 2017-12-27 19:08:08 <arubi> alright let's see
250 2017-12-27 19:08:33 <DSidH> I used dsha256(magic_bytes+message) as the hash
251 2017-12-27 19:08:59 <DSidH> to be precise: [magicBytes size]++[magicBytes size]++[msg size]++[msg]
252 2017-12-27 19:09:13 <DSidH> [magicBytes size]++[magicBytes]++[msg size]++[msg]
253 2017-12-27 19:11:23 <DSidH> perhaps the test ones were generated before core used ref6979
254 2017-12-27 19:13:36 <arubi> getting the same sigs as the ones in MySig
255 2017-12-27 19:14:06 <DSidH> arubi: thanks mySig are ones I generated
256 2017-12-27 19:14:30 <DSidH> any idea why the core test ones are different (at least the op seems to imply its from core)
257 2017-12-27 19:15:22 <arubi> not sure, I'm assuming that if we tell core to sign those messages with the keys, it'll get the same sigs you and I are getting.  how old are the sigs from the test?
258 2017-12-27 19:15:27 <arubi> I mean, how old is the post
259 2017-12-27 19:16:12 <DSidH> post is Mar 1 2014
260 2017-12-27 19:17:34 <arubi> actually I'm not sure when libsecp was merged into core.  I think it was before that..  can you link the post?
261 2017-12-27 19:21:12 <DSidH> https://bitcoin.stackexchange.com/a/22881/2075
262 2017-12-27 19:24:08 <arubi> it reads that they generated these themselves and checked for formatting against core?  not sure.  anyway, for the first sig, the k was either 2AB46A84378337CC07F3A782BDD11E8D10285CA22521CC618FED49E900692133 or D54B957BC87CC833F80C587D422EE171AA8680448A26D3DA2FE514A3CFCD200E .  I tried rfc6979 with the private key and double hash of the message, but that's not it
263 2017-12-27 19:25:06 <DSidH> ok.. thx for validating this
264 2017-12-27 19:25:45 <arubi> np
265 2017-12-27 19:34:27 <arubi> DSidH, confirmed core is getting the same sigs as us
266 2017-12-27 19:50:37 <DSidH> arubi: thanks. btw you were right, segwit is much easier to implement
267 2017-12-27 19:51:04 <arubi> \o/  dat data re-use
268 2017-12-27 19:51:13 <arubi> and witness stacks instead of scripts, oh man