01:16:37 | rusty: | Is there a good primer on EC math anywhere? Coursera's Crypto I didn't cover it, and parsing wikipedia leads me down many garden paths... |
01:17:23 | zooko: | I don't really understand EC math myself, |
01:17:38 | zooko: | but, there is a lecture by DJB that seems to start from first principles. |
01:17:45 | zooko: | So... I'm not really aware of a good primer. :-( |
01:18:51 | gwillen: | rusty: crypto II is supposed to cover it, if he ever does that |
01:19:05 | rusty: | gwillen: indeed, and I'm signed up if and when... |
01:19:15 | gwillen: | current alleged start date is june 1 |
01:19:18 | gwillen: | but we've heard that before ;-) |
01:20:03 | justanotheruser: | rusty: I like the wiki page tbh |
01:20:29 | zooko: | Hm, and I can't find that lecture that I saw. Sorry. |
01:20:43 | rusty: | zooko: https://www.youtube.com/watch?v=l6jTFxQaUJA ? |
01:21:11 | kanzure: | how about http://antoanthongtin.vn/Portals/0/UploadImages/kiennt2/BaiBao/DuLieu/2.State%20of%20the%20art%20in%20applied%20cryptography%201997-LNCS%201528/15280131.PDF |
01:21:29 | zooko: | rusty: that looks perfect. :-) |
01:21:34 | zooko: | * zooko starts watching it |
01:31:28 | zooko: | Whoops, got to go. Just got to the part about how to get away from those tricky non-discrete trig formulas. :- |
01:31:29 | zooko: | ) |
01:33:23 | kanzure: | .title https://www.youtube.com/watch?v=l6jTFxQaUJA |
01:33:25 | yoleaux: | ECCHacks - A gentle introduction to elliptic-curve cryptography [31c3] - YouTube |
01:35:47 | brisque: | I think a lot of people's introduction to bitcoin is hampered by people's poor explanations of ECDSA. you're better off knowing it's properties and otherwise black boxing it than having a half assed understanding that is ultimately meaningless. |
01:37:00 | jcorgan: | ^^ knowing how it behaves and what properties you can assume lets you make better decisions; understanding why those behaviors exist and why the properties are what they are is less important. |
01:46:23 | brisque: | that goes for a lot of things in bitcoin really. |
01:46:37 | brisque: | black boxing shad256d is a nice start. |
01:50:48 | jcorgan: | and there aren't that many black boxes in bitcoin to understand |
01:51:30 | brisque: | sha256d and ecdsa are two that trip people up usually |
01:53:06 | dgenr8: | waiting for crypto II too. DJB is clearly a Knuth disciple as it relates to timelines |
01:53:36 | jcorgan: | well, pay-to-pubkey-hash seems to get universally black-boxed as "an address is an account that holds bitcoin" |
01:55:07 | brisque: | much to the damage of gmaxwell's forehead. |
01:55:24 | jcorgan: | even gribble, our saintly fount of all knowing, makes that mistake |
01:56:28 | brisque: | it's a lot due to block explorers and people's desire to try to "organise" things in particular ways, not realising accounts are a feature of the wallet and utterly unrelated to addresses. |
01:59:22 | jcorgan: | something as simple as "Redeemable Unspent Receipts" as a table header instead of "Addresses and Balances" would go a long way. But people see the latter in pretty much every wallet. |
02:00:53 | brisque: | damage is already done. |
02:01:50 | jcorgan: | and showing two UTXOs with the same pubkey hash should be highlighted in red as "ambiguous" |
02:02:20 | justanotheruser: | !balance 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX |
02:02:21 | gribble: | 0.51465589 |
02:02:34 | brisque: | some PKH have tens or hundreds of thousands of UTXO, enough to crash any browser |
02:04:58 | brisque: | high water mark is 3 million total outputs for one address. |
02:05:54 | jcorgan: | dice? |
02:06:09 | brisque: | you know it. |
02:21:53 | Apocalyptic_: | Apocalyptic_ is now known as Apocalyptic |
02:22:21 | guruvan-: | guruvan- is now known as guruvan |
02:26:21 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
02:27:43 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
03:38:44 | rusty: | rusty has left #bitcoin-wizards |
03:58:32 | instagibbs: | brisque: for the longest time I only knew the high-level black box. Crypto 1 was my first attempt at digging deeper. Little peeved there was no signature/ECC stuff :) |
04:24:46 | kanzure: | what we really need is smart matter that cannot rise above a certain temperature so that nobody will be foolish enough to implement a hot wallet with said matter |
04:36:14 | PaulCape_: | PaulCape_ is now known as PaulCapestany |
04:57:16 | kanzure: | just-vaguely-discernably-warm-wallet |
04:58:42 | kanzure: | (signing should raise the temperature) |
05:19:53 | PaulCapestany: | PaulCapestany is now known as PaulCape_ |
05:45:39 | PaulCape_: | PaulCape_ is now known as PaulCapestany |
06:58:34 | luny``: | luny`` is now known as luny |
09:05:17 | hitchcock.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
09:05:17 | hitchcock.freenode.net: | Users on #bitcoin-wizards: andy-logbot Quanttek d1ggy Guyver2 Dr-G2 cbeams arubi_ rusty damethos hktud0 koshii moa luny grassass p15 face PRab BananaLotus Apocalyptic guruvan justanotheruser PaulCapestany ryan-c dc17523be3 MoALTz lnovy DoctorBTC melvster adlai paveljanik waxwing sipa harrow hashtagg grandmaster prodatalab flower bsm117532 alferz Luke-Jr gribble fanquake delll_ OneFixt amiller go1111111 jgarzik ebfull espes__ cluckj shesek cryptowest c0rw1n brisque |
09:05:17 | hitchcock.freenode.net: | Users on #bitcoin-wizards: cfields sdaftuar mkarrer Starduster Logicwax veorq coryfields dgenr8 devrandom Pan0ram1x helo bosma Hunger- xabbix burcin runeks null_radix bedeho copumpkin Cory gmaxwell Emcy huseby jaekwon_ GreenIsMyPepper sneak SwedFTP bepo LarsLarsen epscy nanotube tromp binaryatrocity spinza andytoshi bliljerk101 tromp__ wizkid057 starsoccer comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate crescendo livegnik optimator fluffypony |
09:05:17 | hitchcock.freenode.net: | Users on #bitcoin-wizards: Meeh cursive yoleaux dansmith_btc [d__d] berndj morcos Fistful_of_Coins dardasaba isis gwillen BlueMatt airbreather dasource smooth phantomcircuit ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis platinuum Oizopower Keefe catlasshrugged JonTitor petertodd kanzure eric mappum jbenet wiz midnightmagic heath gnusha warren Adrian_G Iriez lechuga_ dignork kinlo jessepollak ahmed_ Graet Eliel veox |
09:05:17 | hitchcock.freenode.net: | Users on #bitcoin-wizards: warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck bbrittain jaromil jcorgan wumpus BrainOverfl0w roasbeef phedny so hguux__ otoburb MRL-Relay azariah HM2 btc___ throughnothing @ChanServ brand0 Alanius davout NeatBasis mr_burdell d9b4bef9 a5m0 fenn |
09:38:58 | nickler: | rusty: I really like http://jeremykun.com/2014/02/08/introducing-elliptic-curves/ |
09:39:52 | rusty: | nickler: oh, that looks nice! |
11:59:44 | PaulCapestany: | PaulCapestany is now known as PaulCape_ |
12:00:06 | PaulCape_: | PaulCape_ is now known as PaulCapestany |
12:51:04 | Guyver2: | Guyver2 has left #bitcoin-wizards |
13:42:02 | PaulCapestany: | PaulCapestany is now known as PaulCape_ |
15:03:12 | PaulCape_: | PaulCape_ is now known as PaulCapestany |
15:08:15 | PaulCapestany: | PaulCapestany is now known as PaulCape_ |
15:14:44 | waxwing__: | waxwing__ is now known as waxwing |
17:49:13 | arubi_: | arubi_ is now known as arubi |
18:05:36 | waxwing__: | waxwing__ is now known as waxwing |
18:46:59 | Guyver2: | Guyver2 has left #bitcoin-wizards |
19:47:14 | catlasshrugged: | has anyone come up with a reasonble approximation of calculating the cost of a double spend vs. # of confirmations for a given tx? |
19:47:42 | kanzure: | you mean the cost of mining a reorg? |
19:48:21 | catlasshrugged: | If I understand you correctly, yes |
19:49:41 | kanzure: | catlasshrugged: page 11 https://bitcoin.org/bitcoin.pdf |
19:50:01 | kanzure: | catlasshrugged: and https://people.xiph.org/~greg/attack_success.html |
19:56:29 | catlasshrugged: | kanzure: thanks, those are helpful |
19:56:44 | sipa: | #bitcoin please |
20:08:14 | catlasshrugged: | sorry |
21:17:21 | bramc: | tromp, I didn't remember the bit about three in the holy hand grenade sketch |
21:18:20 | tromp: | oh, it's a classic: http://en.wikipedia.org/wiki/Rabbit_of_Caerbannog#Holy_Hand_Grenade_of_Antioch |
21:19:25 | bramc: | I looked it up after you mentioned it |
21:19:53 | tromp: | then you see how your remark reminded me of it:) |
21:20:03 | bramc: | Yes. Something about how important three is. |
21:20:41 | tromp: | you also said something like 4 is out of the question |
21:20:56 | bramc: | Oh funny |
21:21:01 | tromp: | where they have " Five is right out. " |
21:22:42 | bramc: | There's a bunch of tradeoffs, I'm basically looking for a value which causes pooling rewards for not crazy pool sizes to be nearly nonexistent, and doesn't fall prey to a superfast spow server being overly advantaged. |
21:23:16 | bramc: | There's also a large blowup in the number of messages with the current way of doing things I'm working on |
21:25:31 | tromp: | you should prepare a blog entry with an outline of your scheme, and get a ton of hopefully useful feedback |
21:25:53 | tromp: | also saves you from explaining it here repeatedly:) |
21:26:26 | gmaxwell: | bramc: did I hear that you're up to three SPOWs now? |
21:26:46 | tromp: | no; he has 3 proofs of storage for each spow |
21:27:08 | bramc: | gmaxwell, No it's three pos, followed by a spow whose challenge difficulty is the sum of the quality of the three previous spows |
21:27:20 | bramc: | or maybe their geometric mean, or geometric mean squared, or something like that. |
21:27:26 | gmaxwell: | ah, okay, that isn't as rubgoldbergy as I feared. |
21:28:34 | bramc: | It's less rube goldbergy than what I was working on before, although there's annoying stuff where it needs to be done collaboratively so people send around not just the best first pos but a list of the top few, and the the top few for the first and second based on their quality |
21:29:01 | gmaxwell: | oh that sounds like it has even more progress. |
21:29:31 | bramc: | Because an attacking pool will do that on their own, so you need to do the collaborative thing for the general pool to outdo them |
21:30:26 | bramc: | Not sure what you mean by 'more progress'. Doing things in this way is necessitated because withholding attacks if the pos all used the same challenge are very effective. |
21:31:45 | bramc: | This one has all kind of funny stuff happen where a member of a pool which is trying to withholding attacks defects because they got a winner for pos #3 so they serruptitiously introduce it into the general pool without permission |
21:34:18 | bramc: | Using three pos makes it so that a pool which has a small fraction if everything has only a tiny chance of getting lucky and catching up, to the point where pooling bonus is essentially gone |
21:34:18 | zooko: | Anyone going to the MIT Bitcoin Expo? I am! ☺ |
21:35:36 | kanzure: | if someone could be kind enough to link me to a livestream when it is happening, i can do transcripts and live peanut gallery |
21:35:45 | gmaxwell: | zooko: BlueMatt is I believe. |
21:39:46 | bramc: | It looks like the idea behind op_checktimelockverify is to make it so that funds don't have to keep getting re-deposited as timeouts get hit |
21:39:52 | bramc: | from the lightning paper |
21:40:04 | zooko: | gmaxwell: Sweet. ☺ |
21:40:36 | bramc: | gmaxwell, Going through this exercise has given me a new appreciation for how critical having winner take all is no mining |
21:40:43 | bramc: | on mining |
21:42:23 | bramc: | I think I'll need to sit down with Joe Poon in person and discuss, the paper is fairly opaque. |
22:36:44 | bramc: | The monero project web page isn't praticularly helpful or confidence inspiring. Is there a web page which has a straightforward writeup on how it uses ring signatures? |
22:42:20 | bramc: | The cryptonote white paper sort of talks about it, it seems like the sum total of the whole thing is to make a bunch of counterparties agree on a ring signature and then all send equal sized payments to that ring signature and spend them at their leisure later |
22:43:36 | bramc: | Which honestly seems like an anonymity loss, since utxo signature are one time anyway all that did was link those all together. Maybe it's a bit more convenient than making transactions for unlinking. |
22:45:03 | gmaxwell: | there is no agreements. |
22:46:01 | bramc: | gmaxwell, Thanks, that makes sense. A fun crypto gizmo though. |
22:46:10 | gmaxwell: | there is a UTXO set. You can gather N UTXO of the same value and sign so that your signature shows you're signing on behalf of one of the N. A side effect of the signature is a serial number which is unique per utxo that you're actually spending, that only the signer can compute but which everyone can verify. |
22:46:54 | gmaxwell: | So your input has an anonymity set the size of the ring*, and the signature size is linear in the size of the ring. (*) there are varrious factors that can reduce the anonymity set further. |
22:47:27 | bramc: | What's to stop someone from double spending the utxo? |
22:47:50 | bramc: | Shouldn't it have to go through an intermediary step, where I transfer the utxo to a ring-signature-unlocked utxo? |
22:49:29 | Eliel: | bramc: cryptonote method does not require any cooperation between individual users. The whole idea of the ring signature it's based on is that you can prove that you're one member of a group but not specify which member. |
22:50:01 | gmaxwell: | bramc: that unique serial number. |
22:50:30 | gmaxwell: | bramc: the serial number gets stored and the system prevents any duplicate serial numbers, so no double spend is possible. |
22:50:33 | bramc: | But you still have an input utxo, and input utxos need to be mixed to prevent double spends |
22:50:54 | Eliel: | bramc: umm no, the group is formed from different input utxos. |
22:51:08 | Eliel: | and the signature proves that you know the private key to one of them |
22:51:09 | bramc: | gmaxwell, oh, so spending the original utxo would require the same serial number? |
22:51:21 | gmaxwell: | yep! |
22:51:28 | bramc: | Aaah, that makes it a lot more useful |
22:51:59 | gmaxwell: | You've got it. Yea, I'd tried prior to cryptonote stuff to use ringsigs for privacy and failed due to that issue... the that linkability is the extra part that makes it all work. |
22:52:55 | Eliel: | as long as your private key doesn't leak, your privacy can't be broken. |
22:54:29 | Eliel: | it took me a while to understand how the crypto works but it was worth the time :) |
22:55:21 | bramc: | It does make it a bit more difficult to have a list of unspent utxos :-P |
22:55:39 | Eliel: | was kind of amusing to see that cryptonote signatures consist of mostly random numbers :) |
22:55:56 | Eliel: | bramc: yep, instead you need to keep a list of spent utxo serials. |
22:56:22 | bramc: | Eliel, and a list of all utxos which have existed ever |
22:57:14 | Eliel: | yep, gmaxwell and andytoshi had a solution for that IIRC but I can't recall the details right now |
22:59:10 | bramc: | So then you can use snarks to show that a particular serial came out of the list of all utxos of a particular value which have ever existed? |
22:59:53 | bramc: | Is that what zerocoin does? |
23:01:28 | gmaxwell: | yes, thats what zero_cash_ does. There is a TXO tree H(serial||nonce) and you prove the TXO tree contains the serial you're claiming to spend. |
23:01:32 | brisque: | cnutgktcrblthhktvcvihhfncvncvrvg |
23:01:39 | brisque: | ._. |
23:01:42 | brisque: | sorry. |
23:02:02 | Eliel: | brisque needs a new password :) |
23:04:15 | bramc: | Of course, if you're going that way you can dispense with the ring signature completely and make the 'signature' be a hash preimage reveal |
23:04:31 | MRL-Relay: | [othe] bramc, did u check MRL-0003 ? it explains that stuff u are asking about https://lab.getmonero.org/pubs/MRL-0003.pdf, theres also a python ringsignature port on github |
23:05:09 | bramc: | What is this mrl relay thing? |
23:05:31 | MRL-Relay: | [othe] just a relay bot from monero irc to freenode |
23:06:21 | bramc: | Thanks othe |
23:08:02 | justanotheruser: | gmaxwell: what curve is the blockstream challenge using? Or should that not matter? |
23:08:36 | brisque: | I would be shocked if it wasn't secp256k |
23:09:24 | gmaxwell: | it's secp256k1.. the signatures are just old style armory signatures. |
23:09:35 | justanotheruser: | ok thanks |
23:09:45 | gmaxwell: | I need to put a sage script up that verifies them, seems a lot of people expect them to be invalid. |
23:10:21 | bramc: | gmaxwell, what did you mean about there being progress? |
23:11:32 | justanotheruser: | If they were invalid then that would be a dumb puzzle |
23:11:52 | gmaxwell: | justanotheruser: yea, thats my thinking too! |
23:12:28 | justanotheruser: | though it would be a great troll |
23:12:38 | gmaxwell: | bramc: that larger participants gain more advantage. But I see that you're expecting participants to share their progress. I understand now that you're basically instutionalizing some of the strategic mining we'd talked about before. |
23:13:39 | bramc: | gmaxwell, Yeah it's institutionalizing it but capping it at a small fixed number of generations in |
23:14:08 | bramc: | And yeah, the idea is to make the cooperation squeeze out anyone who tries to form their own separate pool |
23:20:15 | bramc: | Funny thing, zerocash has some clear benefits in terms of having a relatively small block chain |
23:20:32 | bramc: | Because all the public keys are just secure hashes |
23:22:24 | brisque: | aren't their proofs absolutely massive? |
23:22:32 | tromp: | 288 bytes |
23:23:37 | bramc: | I guess it's like using p2sh and overall winds up being a little bit bigger |
23:24:51 | gmaxwell: | it's completely unprunable though. |
23:25:00 | bramc: | unprunable? |
23:25:24 | gmaxwell: | right now you only need <1GB stroage to run a bitcoin full node, because there is no need to retain the past history. |
23:25:27 | bramc: | Oh, you mean zerocash. Yes, it has similar problems to cryptonote but worse |
23:25:59 | bramc: | That appears to be inherent in the design goals. |
23:26:26 | gmaxwell: | Well the cryptonote stuff is unprunable and the signatures are pretty big (well, only a bit bigger than zerocash proofs, I guess). |
23:26:51 | bramc: | The signatures are arbitrarily large, aren't they? |
23:27:01 | bramc: | Because you can throw in any number of other things into your set |
23:27:10 | gmaxwell: | At least in the ZC paper though they require multiple proofs per transaction if you have more than 2 inputs 2 outputs, so 288 is kind of a lower bound (though with more circuits more cases could be covered with a single proof) |
23:27:31 | gmaxwell: | bramc: yes, the signatures are linear in the ring size. |
23:34:14 | justanotheruser: | oh now I feel dumb, I just realized the signature blocks had addresses in them |
23:35:27 | Luke-Jr: | justanotheruser: ? |
23:37:47 | justanotheruser: | Luke-Jr: I asked the curve type for the blockstream challenge, but the fact that it records addresses makes it quite obvious that it's secp256k1 |
23:54:40 | adlai: | [compressed] addresses don't reveal which curve is being used? |
23:55:00 | adlai: | especially not after ripemd160... |
23:55:17 | adlai: | * adlai has encountered a patent violation: https://github.com/krkhan/cl-ecc/blob/master/ecdsa.lisp#L29 |
23:57:29 | gmaxwell: | adlai: uh. I'm not sure why you're saying that; (there is a lot of misinformation about whats actually patented; most patents are _far_ narrower than the general public thinks they are) |
23:58:07 | gmaxwell: | adlai: the point about the addresses is that it would be really screwy to have a bitcoin address on something that wasn't actually a bitcoin address, not that its impossible but it would certantly be messed up to do otherwise. |
23:58:29 | adlai: | * adlai might be taking djb's joke (from https://www.youtube.com/watch?v=l6jTFxQaUJA ) too literally |