1 2012-09-07 00:00:07 <jrmithdobbs> Isis: yes that's absolutely correct
  2 2012-09-07 00:00:14 <gmaxwell> Isis: let me suggest something that is just has horribly insecure, fundimentally but at least would 'work'.
  3 2012-09-07 00:00:49 <Isis> Sure
  4 2012-09-07 00:01:08 <jrmithdobbs> oh goody, gmaxwell's hypotheticals are always entertaining ;p
  5 2012-09-07 00:01:10 <lianj> is wp right that the magnetic stripe has 495 bits of storage?
  6 2012-09-07 00:01:22 <Isis> Depends on the track
  7 2012-09-07 00:01:29 <lianj> all of them
  8 2012-09-07 00:01:30 <jrmithdobbs> and encoding method
  9 2012-09-07 00:01:52 <jrmithdobbs> and any error correction used
 10 2012-09-07 00:01:56 <jrmithdobbs> (which is a must)
 11 2012-09-07 00:02:14 <gmaxwell> Isis: he reads the data on the card. Builds a keypair from it, but it's not a bitcoin key. It's just a key pair: GregPub, GregPriv. Using that data he sends a message requesting the payment to the okpay network: "GregPub: Pay Joe 1.0 BTC"--signed GregPriv.
 12 2012-09-07 00:03:03 <gmaxwell> the network then routes the message to my signing agent(s), who have identified themselves by also producing GregPriv signed messages. They produce the transaction for Joe and send it back to him.
 13 2012-09-07 00:04:37 <gmaxwell> Of course, it's still insecure, but at least it would work. It doesn't have quite as many key management problems, and also doesn't bloat the transactions with an extra highly insecure (due to exposure) key.
 14 2012-09-07 00:04:54 <Isis> The reductionist in me says this is essentially the same thing, but yes I see the difference.
 15 2012-09-07 00:05:10 <jrmithdobbs> gmaxwell: can't you easily fix that by making him send it signed by JoePriv? Then you can display the signing fingerprint (or similar), which should be ideally visibly display at the cash register, on the mobile device which actually does all the real signing?
 16 2012-09-07 00:05:38 <jrmithdobbs> gmaxwell: display JoePub as a QR code at the cash register, that verifies the request came from the merchant
 17 2012-09-07 00:05:40 <Isis> You can get around that by having another auth step before signing such as an sms message.
 18 2012-09-07 00:05:44 <gmaxwell> well it removes some praticle issues (easier to rotate the auth keys, avoids making even larger txn)
 19 2012-09-07 00:05:52 <jrmithdobbs> Isis: no. more auth steps are bad.
 20 2012-09-07 00:06:03 <gmaxwell> jrmithdobbs: if you're displaying a QR code you can just eliminate the whole magstripe thing to begin with.
 21 2012-09-07 00:06:26 <Isis> Assuming the cash register knows WTF a QR code is, most don't.
 22 2012-09-07 00:06:27 <jrmithdobbs> gmaxwell: i'm aware, i'm just saying that would actually secure the system and make it fairly sane
 23 2012-09-07 00:06:35 <gmaxwell> jrmithdobbs: have him display a QR code saying "PAY ME THIS, remit payment to X" you read it, pay, etc.
 24 2012-09-07 00:06:35 <jrmithdobbs> but the magstripe card still adds practically nothing
 25 2012-09-07 00:06:59 <gmaxwell> Isis: and it knows how to make keypairs from data on magstripes? :P
 26 2012-09-07 00:07:06 <jrmithdobbs> gmaxwell: but you wouldn't ever have to share the priv key at least
 27 2012-09-07 00:07:48 <Isis> The gateway software would, yes.
 28 2012-09-07 00:08:13 <Isis> But yeah it's a trivial difference to create it as a bitcoin signing key vs just a private message signing key.
 29 2012-09-07 00:08:22 <jrmithdobbs> Isis: i'm not understanding the benefit of the magstripe card at all, even in this fixed scenario
 30 2012-09-07 00:08:30 <jrmithdobbs> Isis: why do you think it's useful?
 31 2012-09-07 00:08:35 <Isis> What country are you in jrmithdobbs?
 32 2012-09-07 00:08:42 <jrmithdobbs> the us
 33 2012-09-07 00:09:13 <Isis> Imagine going to your local 7/11 and swiping a card and walking out with whatever.  That's the benefit.
 34 2012-09-07 00:09:30 <gmaxwell> I'm sure both jrmithdobbs and I get how desirable it is to replicate the expirence of credit card payment, but I'm pretty sure you can't viably do that.
 35 2012-09-07 00:09:44 <jrmithdobbs> not how you've proposed, anyways
 36 2012-09-07 00:10:08 <Isis> Elaborate jr?
 37 2012-09-07 00:10:11 <jrmithdobbs> I think it could be done sanely with an evp-ish system, but good luck with that in the states thanks to the banks lobbying against security
 38 2012-09-07 00:10:22 <gmaxwell> right, not with a magstripe card at least??? a evp smartcard and a special terminal, yes.. perhaps.
 39 2012-09-07 00:10:42 <jrmithdobbs> gmaxwell: not even that special, just a terminal with some modified firmware
 40 2012-09-07 00:11:44 <gmaxwell> Or even with a normal card and the right kind of antifraud agreements that put most of the liability on the merchant, as happens with regular card processing.. sure.
 41 2012-09-07 00:12:01 <jrmithdobbs> i'm not comfortable endorsing such a system as that
 42 2012-09-07 00:12:10 <gmaxwell> meh. I said viable, I didn't say good.
 43 2012-09-07 00:12:12 <jrmithdobbs> because that system has shown to be a massive failure, imho
 44 2012-09-07 00:12:39 <gmaxwell> It's a huge success, everyone uses it. It's gawdy and has tons of externalized costs, and is hugely profitable for all involved. :P
 45 2012-09-07 00:12:45 <jrmithdobbs> but maybe i'm biased (says the man whose cards have been revoked like 10 times in 2 years due to compromised readers in stores and similar)
 46 2012-09-07 00:13:11 <jrmithdobbs> gmaxwell: i'll rephrase, a massize failure for the consumer.
 47 2012-09-07 00:13:20 <jrmithdobbs> it's fine for everyone else involved, sure ;p
 48 2012-09-07 00:13:30 <gmaxwell> jrmithdobbs: I just had a card hijacked myself.. bank calls me up "um. You're not buying dozens of plane tickets in sao paulo are you?"
 49 2012-09-07 00:13:51 <jrmithdobbs> gmaxwell: we had a local (good) resturaunt get beiged boxed
 50 2012-09-07 00:14:02 <jrmithdobbs> gmaxwell: and I mean that literally. a beige box on the hard line
 51 2012-09-07 00:14:19 <jrmithdobbs> took them months to figure it out
 52 2012-09-07 00:15:02 <DBordello> Any expected problems with large wallets?  Mine is pushing 12MB
 53 2012-09-07 00:15:07 <gmaxwell> With normal magstripe systems anyone who swipes your card can immitate you and rob it blind. This isn't pure failure due to agressive automated fraud detection and contracts that put most of the liability of disputes squarely on the parties in a position to copy the card.
 54 2012-09-07 00:15:23 <gmaxwell> DBordello: how'd you manage that?
 55 2012-09-07 00:15:38 <DBordello> gmaxwell, I imagine lots of new addresses
 56 2012-09-07 00:16:13 <gmaxwell> DBordello: in any case, no... though the software does get slower if there are a uberton of addresses in the wallet. but tens of thousands appear to work okay.
 57 2012-09-07 00:16:37 <DBordello> gmaxwell, I haven't observed any issues
 58 2012-09-07 00:16:58 <DBordello> 1600 accounts, not that many I guess
 59 2012-09-07 00:17:16 <kjj_> I've heard people complain that the blockchain download is slow if they move a big wallet to a new computer (or get a corrupt chain file)
 60 2012-09-07 00:18:36 <gmaxwell> kjj_: hm. I tested a while back and the chain download was the same speed with 10,000 addresses in the wallet as 100. Maybe I needed more addresses than that or we broke something.
 61 2012-09-07 00:19:00 <jgarzik> 
ACTION wonders if we need the optimization where one stores a keypair with a height (or date)

 62 2012-09-07 00:19:08 <jgarzik> don't check them, if block < keypair date
 63 2012-09-07 00:19:33 <kjj_> the last guy that I heard from personally had a wallet.dat that was over 100 MB
 64 2012-09-07 00:21:19 <gmaxwell> jgarzik: it would be prudent, the spv clients do this to huge success.
 65 2012-09-07 00:21:29 <Isis> Ok guys, thanks for the conversation.  Lots of food for thought.  I'll be back in a bit.
 66 2012-09-07 00:21:32 <gmaxwell> jgarzik: we should probably revise the privkey dump format to allow including the date if we do that.
 67 2012-09-07 00:23:55 <kjj_> most of the stall when importing a private key is rechecking the entire chain, isn't it?
 68 2012-09-07 00:28:30 <gmaxwell> kjj_: all of it.
 69 2012-09-07 00:29:08 <kjj_> having the block chain indexed by output address would fix that too, I guess.
 70 2012-09-07 00:29:39 <kjj_> but adding a "created on" field to the WIF would be cheaper in dev time
 71 2012-09-07 00:30:20 <jrmithdobbs> Isis: please tell me you haven't already fleeced money out of venture captalists or similar to implement this. Please.
 72 2012-09-07 00:31:12 <gmaxwell> kjj_: there isn't really any development required for an address index, we don't have one because of the space required and because it's not _needed_ currently.
 73 2012-09-07 00:33:03 <jrmithdobbs> Isis: that was a serious question, btw, no matter how poorly phrased.
 74 2012-09-07 01:13:25 <Isis> Sorry jr was AFK
 75 2012-09-07 01:13:31 <Isis> Only money in this is mine.
 76 2012-09-07 01:14:02 <Isis> Search OpenPay on the bitcointalk forums, you'll see how the idea has been evolving.
 77 2012-09-07 01:15:13 <Isis_AFK> bbiab gotta put the kids to bed.  Would love to discuss how to make the general concept work, ideas are always helpful.
 78 2012-09-07 02:02:01 <freewil> is there any info (link?) about Gavin's presentation he gave to the CIA?
 79 2012-09-07 02:03:38 <kjj_> https://bitcointalk.org/index.php?topic=6652.msg251755#msg251755
 80 2012-09-07 02:04:04 <freewil> great thanks kjj_
 81 2012-09-07 02:10:29 <Isis> I'm back
 82 2012-09-07 02:15:43 <jrmithdobbs> Isis: did you see my question earlier?
 83 2012-09-07 02:16:08 <jrmithdobbs> 21:30 < jrmithdobbs:#bitcoin-dev> Isis: please tell me you haven't already fleeced money out of venture captalists or similar to implement this. Please.
 84 2012-09-07 02:21:36 <Isis> Yes did you see my answer earlier?
 85 2012-09-07 02:22:13 <Isis> [21:13] <Isis> Only money in this is mine.
 86 2012-09-07 02:22:14 <Isis> [21:14] <Isis> Search OpenPay on the bitcointalk forums, you'll see how the idea has been evolving.
 87 2012-09-07 02:38:36 <Isis> its quiet in here
 88 2012-09-07 03:29:24 <Graet> yes
 89 2012-09-07 03:46:45 <gmaxwell> "The sharks with frickin??? GPUs attached to their heads will overheat and die."
 90 2012-09-07 03:49:26 <gmaxwell> amiller: thats an excellent post by the way.
 91 2012-09-07 03:49:39 <gmaxwell> (https://bitcointalk.org/index.php?topic=99631.msg1166787#msg1166787)
 92 2012-09-07 03:50:09 <gmaxwell> I sometimes whine that you've gone off all academic navel gazing on me, but I think you're really talking about the important questions there in a way that I wish more people would.
 93 2012-09-07 03:51:12 <gmaxwell> amiller: I'd also add, if you do any analysis along the mining as a commodity lines that commodity mining doesn't necessarily mean totally indifferent miners.
 94 2012-09-07 03:53:09 <amiller> thank you!
 95 2012-09-07 03:53:23 <gmaxwell> amiller: For example, the mining agent software that luke maintains (BFGminer) imposes varrious validity checks on the work its being asked to do. A miner could refused to 'swollow its own tail'??? to do work that would overwrite work it did a while ago, or work involving suspect timestamps, etc..  An economically rational miner might happily sell out his computing time, but the fair price for usage that looks like an attack would probably be
 96 2012-09-07 03:53:25 <amiller> fwiw i hope you stay grumpy, i find it motivating, and it's kinda necessary
 97 2012-09-07 03:53:39 <gmaxwell> (though I don't know how you could reason about that concretely)
 98 2012-09-07 03:54:44 <kjj_> gmaxwell: does it hop to a secondary work source if the first feeds it garbage?
 99 2012-09-07 03:55:59 <gmaxwell> (in theory that kind of bullshit detection could potentially go into silicon in next gen mining asics: perhaps individually us miners might not be altruistic enough to not defect, but putting good behavior in silicon might be an economically efficient way to precommit to honesty)
100 2012-09-07 03:56:30 <gmaxwell> kjj_: I don't know if it just warns now or if it currently switches away, it's only a fairly recent thing. It certantly could be made to switch away.
101 2012-09-07 03:57:00 <kjj_> that would require much smarter ASICs than anything currently existing
102 2012-09-07 03:57:34 <kjj_> I just saw BFG recently.  haven't been keeping up with mining technology since I started p2pcoin
103 2012-09-07 03:58:17 <kjj_> it looks really cool, so when I get some time I'll probably work on switching p2pcoin over to it.  phoenix had some advantages early on, but I think they've dried up now
104 2012-09-07 03:59:00 <gmaxwell> kjj_: there are no asics currently existing. :P (at least as far as anyone has proven). It would be quite easy to keep a list of prev headers and prev timestamps and refuse to cut back our own chain without at least a power off first.
105 2012-09-07 03:59:40 <kjj_> well, right.  but I mean it would take ASIC that were very different from the FPGAs we have now, and different (from what I can tell) from the ASICs that are currently in design
106 2012-09-07 04:00:32 <kjj_> I went poking around the BFG code today and the current FPGAs take the midstate, which tells the device almost nothing about the block.
107 2012-09-07 04:00:53 <kjj_> all of the software miners (including openCL) also start from the midstate
108 2012-09-07 04:01:10 <gmaxwell> yep, though its just low speed logic.
109 2012-09-07 04:03:06 <kjj_> I'm not sure it would be possible for the chip to validate anything unless you feed the whole header in.
110 2012-09-07 04:05:06 <kjj_> which would be easy enough, and it would only cost a single round of SHA (the midstate round), which is nothing when you have a chip doing billions per second.
111 2012-09-07 04:06:19 <kjj_> I think that idea will have to wait until the second generation of ASICs though, unless BFL and company are all lying about their production schedules
112 2012-09-07 04:06:55 <gmaxwell> kjj_: right, which would also reduce communication bandwidth. (the header is smaller than the midstate)
113 2012-09-07 04:07:03 <gmaxwell> oh it would, I'm sure.
114 2012-09-07 04:07:23 <gmaxwell> It would need to be a norm in mining software first, I think.
115 2012-09-07 04:07:49 <kjj_> are you sure about the size?  I'm pretty sure the midstate is 256 bits
116 2012-09-07 04:08:19 <gmaxwell> IIRC it's 256 bits plus the other half of the header.
117 2012-09-07 04:08:32 <gmaxwell> but maybe I'm being daft, it's not an uncommon occurance.
118 2012-09-07 04:09:13 <kjj_> well, we aren't talking about many bytes in either direction
119 2012-09-07 04:09:35 <gmaxwell> hah true.
120 2012-09-07 04:10:08 <kjj_> midstate is 32 bytes, 256 bits.  exactly the same size as the first chunk of the header
121 2012-09-07 04:12:33 <kjj_> oops, the chunk size of SHA-256 is 512 bits, not 256.  the midstate is smaller by half
122 2012-09-07 04:15:24 <kjj_> the bigger problem might be in parallelization and registers.
123 2012-09-07 04:49:12 <gmaxwell> kjj_: there is a four billion to one work reduction before that point, since the number of rounds in a sha256 engine is quite small compared to n*4 billion it should be a non issue.
124 2012-09-07 04:51:12 <gmaxwell> e.g. even if the front end's midstate compression is just a rolled single stage, it only has to produce one output per four billion steps of the inner loop. And so even if that single stage is much slower than the unrolled stages...
125 2012-09-07 04:52:03 <Joric> http://marsweather.com/data it would be cool to use that for gambling :D
126 2012-09-07 06:55:14 <Luke-Jr> tcatm: ping
127 2012-09-07 08:43:22 <MC1984> rc2 seems a bit less responsive than rc1
128 2012-09-07 08:47:16 <sipa> MC1984: nothing changed that could influence performance, iirc
129 2012-09-07 10:47:05 <riush> how did this tx get accepted? shouldn't the min size limit be 100 bytes? http://blockexplorer.com/tx/3a5e0977cc64e601490a761d83a4ea5be3cd03b0ffb73f5fe8be6507539be76c
130 2012-09-07 11:19:10 <Joric> "scriptSig":"1" huh
131 2012-09-07 11:20:51 <kjj_> look at what it is trying to redeem
132 2012-09-07 11:21:37 <lianj> lets redeem 0 btc, nice
133 2012-09-07 11:23:10 <lianj> anyhow, the question still stands, shouldnt < 100 bytes tx be dismissed anyway?
134 2012-09-07 11:23:58 <edcba> why < 100 ?
135 2012-09-07 11:24:55 <lianj> edcba: https://en.bitcoin.it/wiki/Protocol_rules#cite_note-1
136 2012-09-07 11:26:52 <edcba> transaction
137 2012-09-07 11:27:17 <kjj_> heh, the codes doesn't check minimum transaction size
138 2012-09-07 11:28:14 <edcba> ok it's 86 bytes
139 2012-09-07 11:28:38 <edcba> and that rule of 100 bytes seems arbitrary
140 2012-09-07 11:29:32 <lianj> so delete it? if the reference client doesnt check for it
141 2012-09-07 11:31:32 <kjj_> hmm.  I might not be looking in the right place, but it is CTransaction::CheckTransaction in main.cpp
142 2012-09-07 11:31:48 <kjj_> the only size check I see is that the transaction is less than a million bytes (the max block size)
143 2012-09-07 11:33:11 <lianj> right, the fact that this and other < 100 bytes tx are in the main blockchain already proves that its not checked. wonder why the rule got written in the wiki and if it should be deleted
144 2012-09-07 11:33:45 <sipa> lianj: i believe it once did
145 2012-09-07 11:33:51 <kjj_> the wiki page you are looking at is for tx messages in the network protocol
146 2012-09-07 11:33:52 <sipa> but only as a mempool check
147 2012-09-07 11:33:57 <sipa> so like the current IsStandard()
148 2012-09-07 12:51:36 <Diapolo> Anyone an idea what that is? "Received CTCP 'VERSION' (to Diapolo) from frigg" I'm really no IRC pro.
149 2012-09-07 12:52:01 <Diapolo> I get it everytime I login since a few days.
150 2012-09-07 12:52:06 <sipa> it means frigg sent a request for your version, and your client probably answered
151 2012-09-07 12:52:09 <edcba> it means you have been hacjer
152 2012-09-07 12:52:13 <edcba> hacked
153 2012-09-07 12:52:13 <sipa> oh please
154 2012-09-07 12:52:40 <sipa> anyone has an idea who owns address http://blockchain.info/address/17jruemRwRU2NKZhN7UgPkNDbiDE7rZ9q7
155 2012-09-07 12:52:43 <sipa> ?
156 2012-09-07 12:52:52 <edcba> ok it means you will be hacked :)
157 2012-09-07 12:53:00 <Diablo-D3> no it doesnt.
158 2012-09-07 12:53:12 <Diablo-D3> frigg is the freenode utility bot
159 2012-09-07 12:53:22 <Diablo-D3> it keeps anonymous statistics of users
160 2012-09-07 12:53:32 <edcba> anonymous :)
161 2012-09-07 12:53:40 <Diapolo> Diablo-D3: thanks for that info ... find it annoying ^^
162 2012-09-07 12:53:40 <edcba> of course we have pseudonyms :)
163 2012-09-07 12:53:41 <Diablo-D3> edcba: yes, because its your fucking client version
164 2012-09-07 12:53:49 <Diablo-D3> Diapolo: read the miotd, its clearly listed
165 2012-09-07 12:54:10 <Diablo-D3> and why would it be annoying? if your client isnt a pile of shit you dont even notice
166 2012-09-07 12:54:21 <Diapolo> It' Pidgin
167 2012-09-07 12:54:26 <Diapolo> +s
168 2012-09-07 12:55:01 <Diablo-D3> why the fuck would you irc with pidgin?
169 2012-09-07 12:55:12 <Diablo-D3> go get a real irc client you noob
170 2012-09-07 12:56:03 <Diapolo> Diablo-D3: sometimes you behave like a know-it-all, which I don't like
171 2012-09-07 12:56:07 <sipa> Diapolo: i think xchat is a nice irc client for windows (see www.silverex.org)
172 2012-09-07 12:56:11 <sipa> Diapolo: and ignore Diablo-D3
173 2012-09-07 12:56:44 <Diapolo> sipa: thank's I'll take a look
174 2012-09-07 12:56:59 <Diablo-D3> sipa: erm no
175 2012-09-07 12:57:03 <Diablo-D3> thats exactly what I recommend
176 2012-09-07 12:57:14 <Diablo-D3> silverex's build of xchat on windows, xchat mainline on linux
177 2012-09-07 12:57:24 <Diablo-D3> the only way we'll ever get a better irc client is if I just code one myself
178 2012-09-07 12:57:26 <Diablo-D3> and fuck that shit
179 2012-09-07 12:57:41 <sipa> the point is certainly not your suggestion, but the way you brind it
180 2012-09-07 12:57:45 <sipa> *bring
181 2012-09-07 12:59:14 <Diablo-D3> yes, Im honest and straight across the board
182 2012-09-07 12:59:17 <Diablo-D3> I dont sugar coat shit
183 2012-09-07 13:28:27 <lianj> is http://blockexplorer.com/rawblock/000000000000056b1a3d84a1e2b33cde8915a4b61c0cae14fca6d3e1490b4f98 supposed to have the blockheight in coinbase?
184 2012-09-07 13:31:13 <kjj_> yeah, if the version is 2, the coinbase needs to start with the block height
185 2012-09-07 13:31:37 <kjj_> that one looks like it is off by 6.  let me take a look at the code
186 2012-09-07 13:32:04 <lianj> how to unpack the block height
187 2012-09-07 13:32:38 <gmaxwell> Eliel: I'm becoming convinced.
188 2012-09-07 13:32:47 <lianj> "03190403055049994e5afabe6d6d..." but 197657 unsigned int => "19040300"
189 2012-09-07 13:33:12 <sipa> gmaxwell: of?
190 2012-09-07 13:33:39 <kjj_> ahh, hex
191 2012-09-07 13:33:47 <gmaxwell> Luke-Jr: doesn't eclipse use your poolserver?
192 2012-09-07 13:34:21 <gmaxwell> sipa: Eliel was saying that bitcoin should enforce the correct height in the coinbase for it's own (e.g. getblocktemplate) submitted blocks that have v=2, _now_.
193 2012-09-07 13:34:26 <kjj_> first byye is the number of bytes
194 2012-09-07 13:34:45 <gmaxwell> so that broken miners fail fast. (better to fail right after upgrading software than at some mysterous point months from now)
195 2012-09-07 13:35:31 <lianj> kjj_: i figured that much.. but why. https://github.com/bitcoin/bitcoin/pull/1526/files#L0R3701
196 2012-09-07 13:36:12 <jgarzik> gmaxwell: that was my original suggestion
197 2012-09-07 13:36:16 <jgarzik> but it got shot down :)
198 2012-09-07 13:37:39 <lianj> kjj_: why is it a script and the first 0x03 is pushdata of the stripped uint?. or what am i missing
199 2012-09-07 13:38:29 <lianj> irb(main):011:0> Bitcoin::Script.new( ["03190403055049994e5.."].pack("H*") ).chunks.first.ljust(4, "\\x00").unpack("I")[0]   => 197657  works, but thats wtf
200 2012-09-07 13:38:50 <sipa> lianj: because coinbases do (unfortunately) get parsed for the sigop limit check
201 2012-09-07 13:39:04 <sipa> lianj: and not encoding pushed data in coinbases as scripts could have nasty consequences otherwise
202 2012-09-07 13:39:44 <lianj> sipa: thanks you, that explain it (unfortunately)
203 2012-09-07 13:40:05 <lianj> and why is it not 0x04 for uint?
204 2012-09-07 13:40:14 <sipa> why waste a byte?
205 2012-09-07 13:40:35 <lianj> so i dont have to add it :P
206 2012-09-07 13:40:45 <gmaxwell> lianj: it's required to be in the canonical form, in fact.
207 2012-09-07 13:41:01 <gmaxwell> (did someone update the BIP to make that clear)
208 2012-09-07 13:41:59 <jgarzik> gmaxwell: I think "canonical" is a poor word
209 2012-09-07 13:42:25 <kjj_> I think Gavin prefers to call it minimal form
210 2012-09-07 13:42:34 <jgarzik> gmaxwell: "canonical"... to what?
211 2012-09-07 13:42:37 <lianj> gmaxwell: ok, so i dont see it as uint?
212 2012-09-07 13:42:48 <kjj_> but the BIP is being updated, or has been updated, so that the minimal form is the canonical form
213 2012-09-07 13:42:49 <jgarzik> gmaxwell: someone needs to poke genjix to un-freeze BIP 34
214 2012-09-07 13:43:03 <jgarzik> lianj: numbers in scripts are bignums
215 2012-09-07 13:43:13 <jgarzik> lianj: encoded as little endian
216 2012-09-07 13:43:47 <jgarzik> lianj: i.e. MPI format, sans 32 bit size, byte reversed
217 2012-09-07 13:44:08 <jgarzik> lianj: https://github.com/jgarzik/pynode/blob/master/bitcoin/bignum.py
218 2012-09-07 13:44:41 <lianj> "03190403" is not really a number in script terms, just a pushdata of 3 bytes, right?
219 2012-09-07 13:45:13 <sipa> every data element in the script stack is really a bignum
220 2012-09-07 13:45:51 <jgarzik> well, vch-which-may-be-interpreted-as-bignum-depending-on-context
221 2012-09-07 13:46:10 <sipa> right, that
222 2012-09-07 13:46:12 <kjj_> thank god we don't use DER
223 2012-09-07 13:46:22 <lianj> sipa: jgarzik: thanks!
224 2012-09-07 13:46:38 <sipa> kjj_: except for DER being big-endian, there is really very little difference
225 2012-09-07 13:47:38 <kjj_> sipa: we can explain cscript serialization in 5 minutes.  reading the DER spec is fatal in less time than that
226 2012-09-07 13:48:15 <jgarzik> heh
227 2012-09-07 13:48:20 <kjj_> not to mention the silly type field
228 2012-09-07 13:48:33 <gmaxwell> jgarzik: there are multiple ways to represent the values. There is a unique shortest way. We deem the unique shortest way to be the canonical one. I used the word 'canonical' because there may be other cases where we force things to a canonical form which aren't about shortness.
229 2012-09-07 13:48:54 <gmaxwell> An example of this is in the 'negative' handling for the signatures.
230 2012-09-07 13:49:05 <sipa> by the way, i read blockchain.info patched to use DER signatures now
231 2012-09-07 13:49:29 <sipa> however, i recently found a non-canonical one relayed by them still
232 2012-09-07 13:49:33 <gmaxwell> So the goal is canonical form, in the case of integers the method which is canonical is the shortest expression.
233 2012-09-07 13:49:38 <gmaxwell> sipa: cached JS?
234 2012-09-07 13:49:55 <jgarzik> gmaxwell: this is -your- definition of "canonical" as it is not recorded anywhere considered canonical
235 2012-09-07 13:50:00 <jgarzik> that was my point
236 2012-09-07 13:50:27 <sipa> ok, let's switch to the formulation "The BIP defines are canonical format heights are required to be encoded in"
237 2012-09-07 13:50:38 <jgarzik> gmaxwell: you cannot just say "canonical form" and expect everyone to know precisely what you mean.
238 2012-09-07 13:50:41 <gmaxwell> jgarzik: it's recorded in the source code that enforces it. The BIP is supposted to get fixed but its locked.