| 00:02:26 | rusty: | op_mul: A BIP might be overkill, but gathering wallet privacy "best practice" in one place might be a start? |
| 00:05:30 | bramc: | By compressed keys, you means one where the secure hash is given? |
| 00:06:30 | op_mul: | no. EC points can be "compressed" by just showing the sign of Y rather than the whole integer. |
| 00:07:14 | rusty: | bramc: https://en.bitcoin.it/wiki/Protocol_specification#Signatures |
| 00:07:47 | bramc: | Oh right. That would seem to be a ridiculous no-brainer |
| 00:08:08 | op_mul: | up until recently the majority of all signatures were from non-compressed point keys. |
| 00:09:19 | rusty: | bramc: yeah, but they weren't used originally. So now it requires upgrading wallet software, which means new wallets won't work with old software... |
| 00:09:48 | op_mul: | it's supported in core since like 2011 |
| 00:13:06 | rusty: | op_mul: hey, that's only 4 years, don't rush us! |
| 00:14:05 | op_mul: | rusty: https://github.com/blockchain/My-Wallet/commit/1c04bef8fe2afb5f20035067d42a2277cdef82cb#diff-f3aa2b02abfd24669b81e0d6a8f54557R722 |
| 00:15:14 | phantomcircuit: | ha it's literally like 8 lines |
| 00:16:18 | rusty: | phantomcircuit: sure, but that's changing the default, not supporting them in the first place. |
| 00:16:31 | op_mul: | their library supported it since 2011. |
| 00:17:09 | op_mul: | you see, users panic when they export their private keys and it doesn't begin with a 5 |
| 00:17:14 | gmaxwell: | op_mul: likely since the day it was written. |
| 00:17:18 | gmaxwell: | there is basically nothing to do to support it in most software. |
| 00:18:41 | op_mul: | yes. you can see why I don't think there's any use bugging wallet devs about minor privacy quirks. |
| 00:19:39 | rusty: | op_mul: no, you want their users to do that. Which means that they have to know about it... |
| 00:22:03 | op_mul: | rusty: I think I would have a hard time convincing people to be upset about it. |
| 00:24:07 | rusty: | op_mul: I believe the way modern kids do it is to register www.areweprivateyet.com, which takes a txid. |
| 00:28:34 | op_mul: | rusty: I have no intention of putting myself at risk for the sake of other peoples privacy. |
| 00:57:58 | bramc: | op_mul, I would hope that most bitcoin users aren't posting about their transactions to bitcointalk and reddit |
| 00:58:25 | op_mul: | bramc: you'd be surprised. |
| 00:58:45 | bramc: | That doesn't bode well for the total number of bitcoin users or how mainstream they are |
| 01:00:05 | op_mul: | I think there's a lot lower use of bitcoin than most people estimate. a large amount of the transaction volume is spammy or otherwise obviously non-human. |
| 01:07:02 | bramc: | That sounds likely. There's a lack of actual commerce one can point to getting enabled by bitcoin |
| 01:08:23 | bramc: | And the price differences on the exchanges indicate sky-high counterparty risk |
| 01:13:55 | bramc: | It will be interesting to see what happens when transaction limits start getting hit. My guess is that transaction costs will rise only slightly, because most of what's happening is garbage, but it will be enough to obliterate the colored coins |
| 01:19:11 | op_mul: | bramc: I don't imagine it will be for a long time |
| 01:19:55 | bramc: | It's roughly a factor of 5 off right now |
| 01:41:26 | petertodd: | bramc: wtf do you think colored coins will give a damn about tx costs? |
| 01:42:09 | petertodd: | bramc: you realise it's easy to do them in ways where moving one "colored coin" is encoded essentially identically to moving bitcoin value, with identical costs |
| 01:42:51 | bramc: | petertodd, colored coins generally are using de minimis nominal values for transfers. If transaction costs became significant they couldn't even do transfers |
| 01:43:21 | bramc: | And why are you cursing at me? I've been making mild comments and you've been going into a rage. |
| 01:43:44 | petertodd: | bramc: huh? the "nominal value" has nothing to do with the value of the asset being moved |
| 01:44:01 | petertodd: | bramc: and don't think this is a "rage" - I'm just incredibly confused how you would think that |
| 01:44:31 | bramc: | If a colored coin works by having it use a bitcoin which is 1/100th its 'real' value, then its transaction costs are 100 times what the equivalent bitcoin transaction would be |
| 01:44:55 | petertodd: | no, the costs in terms of real value are identical |
| 01:45:36 | bramc: | That isn't my understanding of how colored coins work. They basically mooch off bitcoin's network and pay transaction fees in bitcoins |
| 01:45:43 | petertodd: | if I'm representing a pound of gold with a single satoshi, I don't care that it costs me 10,000 satoshi's - worth a hundredith of a gram of gold - to move that pound of gold |
| 01:45:56 | petertodd: | s/pound/kilogram/ lol |
| 01:46:19 | bramc: | But you need to get those satoshis from somewhere to do the transfer, and you don't have it |
| 01:47:16 | petertodd: | what's hard about just exchanging some gold for bitcoin? |
| 01:47:33 | bramc: | I suppose you could start moving in real bitcoins to pay the fees. Not sure how well the colored coins support that. It certainly changes things when transaction fees get large enough that you have to start keeping some amount of them around |
| 01:47:56 | bramc: | It looks kind of weird if colored coin transactions are almost entirely transaction fees |
| 01:48:17 | pigeons: | ? isnt the point that they are almost entirely transaction fees |
| 01:48:26 | phantomcircuit: | bramc, they correctly support that specifically because of the transaction fees issue |
| 01:48:41 | bramc: | Oh, okay, it won't be that much of a change then I guess |
| 01:49:16 | petertodd: | bramc: yeah, that's trivial... in fact the "colored coin" implementation I'm working on doesn't even call them colord coins anymore - it just uses bitcoin as an anti-doublespend mechanism, quite possibly entirely separate from the logical DAG of asset movement proofs |
| 01:50:27 | petertodd: | that's why I said the danger of this "bitcoin 2.0" stuff is pretty much all the btc2.0 applications are far more valuable per transaction than actually moving bitcoins around - e.g. if securing an audit cost $50/tx lots of companies wouldn't even blink |
| 01:50:29 | bramc: | Well, you could pool together a bunch of transactions to a single hash root... |
| 01:50:54 | phantomcircuit: | bramc, as petertodd is saying things like counterparty aren't even colored coins; they simply use bitcoin to provide ordering and withholding resistance |
| 01:50:57 | petertodd: | bramc: exactly, I'll be getting around to implementing exactly that at some point |
| 01:51:24 | phantomcircuit: | and they have some degree of censorship resistance in that if you find any miner willing to mine them it's likely they'll en dup in the blockchain |
| 01:51:30 | bramc: | Ah, I see your point now. Twitter is a lousy medium for having a discussion. |
| 01:51:34 | petertodd: | phantomcircuit: and remember counterparty is just the beginning of this stuff - anti-doublespend doesn't even need anything other than hashes to be in the blockchain |
| 01:52:12 | phantomcircuit: | petertodd, sure but then you need to incentivize people not to withhold |
| 01:52:21 | petertodd: | phantomcircuit: it's *very* easy to design these systems in ways that are 100% provably unblockable without explicitly whitelisting allowed btc transactions, and heck, you can arrange for that whitelisting to require all users to give up their private keys... |
| 01:55:49 | petertodd: | at state S1, commit to private key Q that controls txout T1, spend that txout in tx X1, which in turn commits to state S2, since spending T1 is a one-shot deal you can't fraudulently create state S2' - tada, secure asset transfer! |
| 01:56:42 | petertodd: | to force whitelits to have users give up thier private keys, make part of commitment in S1 be the private key itself |
| 01:57:38 | petertodd: | to force make anti-censorship have colatteral damage, commit to a n-of-m set of txouts, the minority unrelated to the protocol, and now miners have to prevent all of them from being spent, thus freezing unrelated users' funds in their effort to block the protocol |
| 01:57:58 | petertodd: | *to force censorship to have |
| 02:00:48 | bramc: | petertodd, Do you have a link explaining this? I'd like to spend some time thinking through it later? |
| 02:00:57 | justanotheruser: | petertodd: wouldn't it be better if the guy who actually owned the gold handled all this? What is the point to having a trusty asset on a trustless blockchain? |
| 02:01:49 | petertodd: | bramc: haven't written this up properly yet; writing software to do this |
| 02:02:54 | petertodd: | justanotheruser: outsourcing accounting to the blockchain/software means the issuer doesn't need to be always online, means they aren't in direct control of xfers, etc. etc. |
| 02:05:12 | phantomcircuit: | justanotheruser, nominally it makes no sense; but in practice there are a number of reasons for doing it (some of which petertodd has outlined above) |
| 02:07:34 | kanzure: | it would be interesting to have a correctness proof for certain kinds of audits [as long as you plug in some correctness assumption about bitcoin consensus maybe] |
| 02:09:02 | kanzure: | i don't have a good sense for what percent of audit events haven't had appropriate cryptography identified yet |
| 02:09:52 | kanzure: | i mean the types of audit actions (check a balance, check validity, check permissions against some external record? what else do actual audits need?) |
| 02:10:01 | justanotheruser: | petertodd: It seems like the use cases for that are narrow. You must both have strong trust for the issuer and weak trust for any other authority in the world that could host the transaction system. The owner of the gold would also be choosing to leave his customers with all the weaknesses of distributed consesus rather than having a strong centralized consensus that is near instant (for a potentially higher fee). Is ... |
| 02:10:05 | phantomcircuit: | kanzure, my first guess would be approximately 0% have had sound cryptography applied to them |
| 02:10:07 | justanotheruser: | ... there something I'm missing? |
| 02:10:21 | kanzure: | phantomcircuit: not what i meant, although yes i agree |
| 02:10:43 | phantomcircuit: | justanotheruser, the issuer can be financial secure but technically incompetent |
| 02:10:59 | kanzure: | i mean audit actions themselves. for example, there must be exotic sorts of audit actions that aren't covered by "check permissions, check validity, check balance". |
| 02:11:06 | phantomcircuit: | which is indeed the most common situation |
| 02:11:37 | justanotheruser: | phantomcircuit: right, the narrow case is where the issuer decides not to host, gives up tx fees and you don't want to trust anyone else with your money at the cost of the weaknesses of decentralized consensus |
| 02:11:53 | bramc: | petertodd, Maybe there should be an OP_VERIFY_COLORED_SIDECHAIN |
| 02:12:08 | justanotheruser: | bramc: I don't see why there would need to be a separate opcode |
| 02:12:20 | bramc: | justanotheruser, So you could peg |
| 02:12:24 | justanotheruser: | (separate from OP_SIDECHAIN_VERIFY or whatever its called) |
| 02:12:44 | phantomcircuit: | justanotheruser, there's no reason that a system using bitcoin for ordering couldn't replace bitcoin with another chain |
| 02:13:07 | justanotheruser: | phantomcircuit: did I imply otherwise? |
| 02:13:35 | kanzure: | cross-organization audits can be assisted by public crypto auditing stuff |
| 02:13:44 | kanzure: | for example, maybe your audit only passes if all your suppliers are also passing |
| 02:14:14 | phantomcircuit: | no, i was trying to convey that building the system to be strong enough to work correctly when used in the bitcoin consensus is potentially beneficial to running without bitcoin as it reduces the technical requirements for the outside party to a dumb signing oracle |
| 02:18:30 | kanzure: | i suppose the most useful thing is if you could extend the proofs to an off-blockchain scenario, where you could be reasonably sure about other book data, perhaps a system of fraud proofs and bonds linked to generated audit statements, dunno how this would look. |
| 02:18:56 | kanzure: | *fraud proofs to redeem posted bond amounts... someone suggested this i dunno who. |
| 02:20:17 | starsoccer: | starsoccer is now known as Guest48951 |
| 02:22:02 | justanotheruser: | Also, what promises of assets are reasonably fungible when some authority is holding them? I think the fact that it would usually be large banks holding the reserves in order for the gold to be tradeable (I don't trust gold held by some random guys in Ohio I've never met) makes the set of colored coins uses even smaller. In one case you are just buying the gold as a store of value and you aren't transacting. The issuer ... |
| 02:22:08 | justanotheruser: | ... doesn't need to be online, because you won't be transacting it. In the other case a bank would be handling the gold/other asset and a large central authority can manage a server and reap the rewards from transaction fees with their economy of scale. |
| 02:22:23 | justanotheruser: | excuse my difficult to read english. |
| 02:24:09 | phantomcircuit: | justanotheruser, except you're trusting that entity to not only actually have the correct amount of gold, but also to run the trading system and not screw it up |
| 02:24:31 | phantomcircuit: | as i said before these are rare to find in one place |
| 02:27:32 | justanotheruser: | The incentives for getting transaction fees is pretty high. |
| 02:27:59 | phantomcircuit: | justanotheruser, transaction fees in normal financial systems are typically too small to care about |
| 02:28:09 | phantomcircuit: | except for payment card systems |
| 02:28:15 | phantomcircuit: | those are lulz worthy |
| 02:28:27 | justanotheruser: | hmm |
| 02:29:41 | phantomcircuit: | justanotheruser, for example the fee that your bank charges for electronic ach payments is entirely meaningless to them |
| 02:29:57 | phantomcircuit: | for evidence of this look at what they charge you to handle paper checks: $0.00 |
| 02:30:11 | justanotheruser: | phantomcircuit: I assume it is an anti-DoS feature? |
| 02:30:32 | justanotheruser: | err wrong word |
| 02:30:40 | justanotheruser: | I assume it is just so it is costly for me to abuse it |
| 02:31:09 | phantomcircuit: | justanotheruser, i think it was just a "because we can and fuck you" type fee |
| 02:31:41 | phantomcircuit: | like telecom companies that put a bunch of fees and taxes and stuff at the end of your bill most of which isn't actually taxes and is just fees they're charging you without cause |
| 02:32:06 | bramc: | The biggest banking fees, at least in the US, are made from charging poor people for going over limit. The ethics of this is exceedingly dubious... |
| 02:32:07 | phantomcircuit: | iirc an ACH transaction costs them something like $0.000045 |
| 02:32:12 | justanotheruser: | anyways, it is strange, but I guess sidechains will be useful for colored coins despite trustlessness since the bitcoin network has little downtime |
| 02:32:43 | phantomcircuit: | bramc, i strongly suspect that mostly has to do with trying to get rid of them as customers without actually just closing their accounts |
| 02:32:44 | bramc: | Using the bitcoin blockchain reduces the changes that an alt network will die from disinterest |
| 02:32:59 | bramc: | phantomcircuit, no the banks make good money off of them |
| 02:33:21 | phantomcircuit: | bramc, i kind of doubt it actually |
| 02:33:33 | justanotheruser: | bramc: That isn't a concern of mine really. I don't think assets will account for more than a small fraction of bitcoin fees at any time |
| 02:33:52 | justanotheruser: | how often do you exchange promises of assets and how often do you exchange money |
| 02:35:07 | phantomcircuit: | bramc, the interesting question is what % of revenues they represent, im guessing it's < 1% |
| 02:36:01 | bramc: | phantomcircuit, Probably depends on whether you look at the financial institution as a whole or just the retail banking part |
| 02:36:38 | bramc: | As a matter of practice there are lots of people who would be paying less in feel if they used prepaid debit cards for everything. Or maybe a paypal card, not sure how those work |
| 02:36:56 | justanotheruser: | I think we should consider how much they will account for in the future. I probably trade a stock on average once a month (and afaik, that is the only promise based asset I own) I probably make 5-6 monetary transactions a day. |
| 02:37:04 | phantomcircuit: | of they could you know... just have overdraft turned off |
| 02:38:05 | bramc: | phantomcircuit, That's a relatively new thing, and banks trick people into turning it on by presenting it as 'overdraft protection insurance' or whatnot |
| 02:38:39 | justanotheruser: | if you don't want to go into debt, don't sign a contract that allows it :/ |
| 02:38:58 | bramc: | I think credit cards make on the order of 25 cents per transaction, it's almost entirely legislatively set, they make all their money off lobbying to be allowed to charge higher fees |
| 02:39:27 | justanotheruser: | bramc: you sure there is a legislative limit? |
| 02:39:40 | justanotheruser: | that seems silly, market forces could easily drive out someone charging too much |
| 02:40:11 | bramc: | No it's a natural monopoly, they mostly have to avoid becoming a regulated entity |
| 02:40:14 | phantomcircuit: | bramc, iirc it's only debit cards that have legislated limits |
| 02:40:36 | phantomcircuit: | maybe not |
| 02:40:38 | justanotheruser: | monopoly? theres visa, mastercard, discover, american express... |
| 02:41:03 | bramc: | It's mostly visa and mastercard, and they collude like nobody's business, and you can't really afford to not accept either of those |
| 02:41:31 | bramc: | discover and especially american express are rejected at a lot of places |
| 02:42:25 | justanotheruser: | bramc: if they made their prices super high, you could afford to reject them, in fact, I bet businesses would start charging a fee if you used them |
| 02:42:27 | bramc: | The biggest problem is that visa and mastercard contractually prohibit vendors from passing the transaction fees on to consumers, which is flargrant monopoly practices, but they've got enough pull to keep the law arm of the law from clamping down on them |
| 02:42:53 | bramc: | And then of course there are some cards with cash-back bonuses. Blech. |
| 02:42:55 | justanotheruser: | then businesses would start taking cash |
| 02:43:11 | bramc: | There's a reason why most businesses still happily take cash |
| 02:43:17 | MRL-Relay: | [othe] are you sure they do? i always charge according to the payment method. visa is more expensive for example than bankwire |
| 02:43:43 | bramc: | Who and where just said that? |
| 02:43:47 | justanotheruser: | I don't think regulation of credit cards are necessary when there is already a free alternative |
| 02:44:04 | justanotheruser: | I have an "othe" in my name? |
| 02:44:36 | bramc: | Mostly their practices are kept somewhat under control because of the possibility of going cash-only. There are obvious problems with cash though. For example, the police might steal your money. |
| 02:52:13 | starsoccer: | starsoccer is now known as Guest54312 |
| 03:50:52 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 04:34:01 | Guest54312: | Guest54312 is now known as starsoccer |
| 04:34:30 | fanquake_: | fanquake_ is now known as fanquake |
| 05:45:18 | _Plebington_: | _Plebington_ has left #bitcoin-wizards |
| 06:35:12 | lclc: | lclc is now known as lclc_bnc |
| 07:59:53 | phantomcircuit: | bramc, vendors are now free to price discriminate based on payment method |
| 08:00:48 | bramc: | phantomcircuit, Is that a new thing? I'm pretty sure I heard that the contracts disallowed passing on fees, but that was a few years ago |
| 08:02:47 | phantomcircuit: | bramc, visa/mastercard has lost a string of antitrust cases many of which went to the supreme court |
| 08:03:03 | bramc: | Oh good, that cheers me up |
| 08:03:14 | bramc: | Sanity prevails |
| 09:05:13 | card.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:13 | card.freenode.net: | Users on #bitcoin-wizards: andy-logbot bsm117532 hearn koshii bramc MoALTz booly-yam-5194_ weex_ platinuum coiner examinr e1782d11df4c9914 TheSeven Aesthetic jgarzik smooth fanquake moa starsoccer copumpkin hashtag Dr-G3 PFate Emcy_ [\\\] wallet42 huseby execut3 spinza Guest90099 cfields Guest89043 Graftec imposter RoboTeddy Luke-Jr Cory nsh nullbyte iddo d1ggy grubles ryanxcharles @ChanServ BananaLotus Xzibit17 justanotheruser Alanius artifexd_ kumavis jbenet luny hktud0 |
| 09:05:13 | card.freenode.net: | Users on #bitcoin-wizards: epscy grandmaster mkarrer hashtagg_ Transisto qwopqwop null_radix dgenr8 ebfull mappum devrandom Oizopower PRab waxwing ryan-c c0rw1n catcow ajweiss DoctorBTC gavinandresen wizkid057 stonecoldpat davout hollandais warren bosma forrestv otoburb ahmed_ PaulCapestany phantomcircuit mortale gribble [d__d] lechuga_ nanotube so HM2 bbrittain Hunger- phedny Apocalyptic michagogo btc___ Muis CryptOprah kinlo andytoshi gwillen gnusha burcin Nightwolf a5m0 |
| 09:05:13 | card.freenode.net: | Users on #bitcoin-wizards: Fistful_of_Coins Meeh s1w jcorgan Anduck btcdrak sneak wumpus BrainOverfl0w hguux_ yoleaux BigBitz delll midnightmagic lnovy sdaftuar tromp_ SubCreative deego warptangent TD-Linux NikolaiToryzin bepo_ samson_ nick1234abcd__ d9b4bef9 jaromil Starduster_ EasyAt berndj crescend1 jaekwon_ Taek azariah eric gmaxwell BlueMatt tacotime go1111111 livegnik isis asoltys_ LarsLarsen brand0 amiller tromp Dyaheon _v3Rve K1773R morcos Eliel_ Guest74833 |
| 09:05:13 | card.freenode.net: | Users on #bitcoin-wizards: dasource Krellan pigeons catlasshrugged xabbix_ fluffypony kanzure heath poggy lclc_bnc dansmith_btc petertodd espes__ Keefe roasbeef JonTitor mr_burdell sl01 yrashk fenn comboy_ MRL-Relay cluckj optimator_ earlz cryptowest wiz coryfields_ harrow` brad___ thrasher` Graet helo throughnothing nickler_ Adrian_G Iriez |
| 12:37:55 | hearn: | hearn is now known as hearn[lunch] |
| 13:22:32 | lclc_bnc: | lclc_bnc is now known as lclc |
| 13:31:02 | hearn[lunch]: | hearn[lunch] is now known as hearn |
| 14:15:54 | gmaxwell: | gmaxwell is now known as Guest23941 |
| 14:50:46 | Guest23941: | Guest23941 is now known as gmaxwell |
| 15:04:55 | lclc: | lclc is now known as lclc_bnc |
| 15:10:18 | lclc_bnc: | lclc_bnc is now known as lclc |
| 15:44:36 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 15:53:21 | amiller: | andytoshi, i can't figure out why your ringsig-blinding is supposed to work |
| 15:53:56 | amiller: | the point is to prevent parties who own the 'chaff' coins in a transaction from proving that their coin wasn't the actual coin being spent |
| 15:54:29 | amiller: | i see how adding a blinding factor to each of the keys prevents them from proving that the ring signature was generated that way, |
| 15:54:42 | amiller: | but can't they still prove that their key image isn't the key image that was spent? |
| 15:57:10 | amiller: | even though you make it so that the ring signature is a representation proof of (P1+Q1, or P2+Q2, or ... etc), and further that you know the exponent for all the blinding factor Q's.... I think the key image is still I(P_actual)^x. |
| 15:57:53 | amiller: | er I = x H(P_actual) |
| 15:58:16 | amiller: | so, if you save your 'x', you can prove you weren't involved later on |
| 15:58:47 | amiller: | for posterity, this comment refers to https://download.wpsoftware.net/bitcoin/wizardry/ringsig-blinding.txt which is dated sep'14 |
| 15:59:58 | gmaxwell: | Yes, but you must do that at the time of signing. |
| 16:00:10 | gmaxwell: | And in particular if you weren't involved you can't prove you weren't involved. |
| 16:01:15 | amiller: | gmaxwell, suppose the real coin is P1 and I owned the coin P2.... |
| 16:01:38 | amiller: | that means I know an x2, such that P2 = g^x2, and H(P2)^x2 = I2 which is not equal to the I used in that transaction |
| 16:01:41 | gmaxwell: | (this scheme itself is not so useful for cryptocurrency usage, so talking about coins isn't so great) |
| 16:02:08 | amiller: | alright swap public key for coin |
| 16:02:12 | gmaxwell: | (because it breaks the ability to use the key images to prevent double spending. It's useful for voting like schemes) |
| 16:02:45 | amiller: | oh. |
| 16:02:57 | amiller: | maybe this has abolutely nothing to do with cryptonote and i totally misunderstood the intended application of this. |
| 16:04:11 | gmaxwell: | Yes, that has nothing to do with cryptonote. It's a comment related to a scheme I have for selecting pseudonymous trusted parties. E.g. "I run this oracle. -- {one of satoshi, fbi, gmaxwell}" and make it so that satoshi and/or fbi cannot prove that they were not the author of the message. |
| 16:04:31 | gmaxwell: | (and obviously not me either; so we can all plausably deny authorship.) |
| 16:04:43 | amiller: | okey doke. i sort of read that and brs-arbitrary-output-sizes.txt and just hallucinated that the topic of both was crypotnote enhancements |
| 16:04:50 | amiller: | sorry! |
| 16:04:56 | gmaxwell: | There is a thing related to cryptonode that andytoshi and I were working on. ... yea that thing. |
| 16:07:06 | gmaxwell: | yea, the genesis of brs-arbitrary-output-sizes.txt is that I first came up with the blinding for that election application; there was a potential attack (when you don't prove knoweldge of the discrete log of the blinding factor), and a way to use it produtively showed up (the value / script blinding). |
| 16:15:52 | zooko: | zooko has left #bitcoin-wizards |
| 16:21:41 | lclc: | lclc is now known as lclc_bnc |
| 17:09:40 | andytoshi: | amiller: sure, it is possible to go out-of-band and prove that your key image was not used (eg if you secret key is x you produce a NIZK that DL of g^x is same as H(g^x)^x) |
| 17:10:00 | andytoshi: | it is also possible to just reveal your x, and there is no way to block that |
| 17:11:16 | andytoshi: | but i'm not sure the motivation of this attack? you'd have to know something about a specific tx that you were linked into and know who to give the NIZK to...the point here was to avoid these kind of info leakage in ordinary use |
| 17:11:52 | andytoshi: | one moment actually, i don't remember how much gmaxwell's blinding scheme does :) |
| 17:12:56 | andytoshi: | oh wait, i'm being stupid, i'm talking about something else entirely, ignore me |
| 17:13:50 | andytoshi: | same hallucination as amiller. must be some andrew-targeting chemical agent out there.. |
| 18:04:53 | samson2: | samson2 is now known as samson_ |
| 18:55:37 | gmaxwell: | andytoshi: well I didn't remember it either, I went and read the thing amiller linked to before commenting. |
| 19:12:27 | andytoshi: | last night i posted the link to the BRS stuff, i thought it was the same link (and amiller was replying to it) |
| 19:18:04 | fluffypony: | http://safecurves.cr.yp.to |
| 19:18:20 | fluffypony: | apparently secp256k1 doesn't meet all of the SafeCurve requirements |
| 19:19:28 | gmaxwell: | fluffypony: this is old and uninteresting; some of the 'requirements' are completely uninteresting to us (and maybe just about everyone). Likewise, I could create a similar marketing page what the ed25519 (and related) curves fail; for example; they have a cofactor. |
| 19:19:57 | gmaxwell: | (which has resulted in completely broken protocols several times in the past, e.g. PAKE schemes.) |
| 19:20:56 | fluffypony: | sure, I just didn't realise DJB had a curves page until now |
| 19:34:29 | gmaxwell: | fluffypony: I'd commented on it at some depth at https://bitcointalk.org/index.php?topic=380482.msg4082496#msg4082496 |
| 19:35:13 | phantomcircuit: | i do like his domain name though |
| 19:35:17 | phantomcircuit: | that's super clever |
| 19:36:11 | fluffypony: | well it is DJB, pretty sure he was given that domain before the Internet even existed (I kid) |
| 19:58:25 | lclc_bnc: | lclc_bnc is now known as lclc |
| 20:04:47 | lclc: | lclc is now known as lclc_bnc |
| 20:56:06 | earlz: | Have there been any significant "wishlist" type things for a transaction v2 format or some such? |
| 20:56:31 | earlz: | I've seen one proposal to make it so everything is effectively p2sh (ie, there is no output script, just a scripthash) |
| 20:56:43 | earlz: | but other than that nothing |
| 20:57:53 | andytoshi: | earlz: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas https://en.bitcoin.it/wiki/Hardfork_Wishlist |
| 20:58:05 | andytoshi: | the latter is not on bitcoin.ninja, i will submit a pr.. |
| 20:59:06 | earlz: | yea, I've seen the hardfork wishlist, but nothing in there covering transactions |
| 21:12:45 | bramc: | earlz, schnorr-based signatures, to allow collaborative signature generation |
| 21:14:32 | earlz: | schnorr.. not heard of that one. I'll have to look it up |
| 21:14:45 | earlz: | do you have a reference for how it applies to bitcoin? |
| 21:16:00 | andytoshi: | earlz: it's a drop-in replacement for ECDSA, the wikipedia article is not bad i think. it's roughly "choose a nonce k, then sig is (s, e) where e = H(m||kG) and s = k - ex" |
| 21:16:39 | bramc: | The main schnorr contender is ed25519. Perhaps the only serious contender. |
| 21:16:41 | andytoshi: | earlz: it is cheaper to verify than ECDSA and is provably secure, unlike ECDSA. we also have a proof that it is "strong" i.e. will not cause transaction malleability by itself |
| 21:17:54 | bramc: | andytoshi, And it allows collaborative signature generation! |
| 21:18:09 | earlz: | Has there been any practical proof that ecdsa could possibly have multiple valid signatures? (ie, transaction malleability) |
| 21:18:17 | andytoshi: | bramc: oh, right, that's a big one! |
| 21:18:27 | earlz: | what do you mean collaborative? |
| 21:18:49 | andytoshi: | earlz: well, if (s, r) is a valid ecdsa sig then (-s, r) is also one. but other than that (and it's an easy one to block by halving the allowable range for s), we don't know of any |
| 21:19:06 | bramc: | earlz, Multiple counterparties can generate a public key signature together in such a way that particular subsets of them can do the signature but no single one of them can. |
| 21:19:24 | earlz: | what benefit does that bring over multisig? |
| 21:19:31 | andytoshi: | earlz: collaborative means we can create a 2-of-2 (or n-of-n multisig) by adding our e values, signing the same message, then adding the resultant s values |
| 21:19:32 | bramc: | It allows the transactions to be smaller and less identifiable |
| 21:19:47 | andytoshi: | earlz: then you get a single signature that cannot be distinguished from a boring old 1-of-1 |
| 21:20:43 | earlz: | hmm interesting |
| 21:21:09 | earlz: | is that scheme at all proved secure? or is it relatively new? |
| 21:22:14 | andytoshi: | earlz: it's secure. not sure there is any proof written up, it'd be really gross because the security properties for multisig are always really technical (formalizing things like anti-collusion is hard) |
| 21:23:33 | earlz: | well, I mean like peer-reviewed and all that |
| 21:23:48 | earlz: | I'm not super knowledgable about how crypto works at that low of alevel |
| 21:23:55 | andytoshi: | does folklore count as peer review? :P |
| 21:24:47 | andytoshi: | the short answer is yes, many people have thrown this idea around, and it's used as a component of other cryptosystems (e.g. attribute-based encryption) which are proven secure and properly peer-reviewed |
| 21:25:43 | bramc: | Using ed25519 instead of ecdsa is hardly considered out there at this point. It should probably be the default for new systems, although there's some caveat about how to implement heirarchical wallets which I haven't learned. |
| 21:27:47 | op_mul: | bramc: there's some shitcoins using it. |
| 21:29:02 | tromp: | so clearly not every shitcoin component is shitty |
| 21:29:30 | op_mul: | bramc: here you go, here's some nutty anti-science and es25519 https://bitcointalk.org/index.php?topic=881427.0 |
| 21:29:46 | op_mul: | it uses 64 bit timestamps! 320 bit hashes! |
| 21:30:57 | tromp: | shockingly, it doesn't claim to be "super-secure" |
| 21:31:18 | tromp: | i mean super-sekure :-) |
| 21:32:16 | op_mul: | tromp: sorry, here's a better one for you. it has proof of node uptime! proof of identity! written in nodejs! https://bitcointalk.org/index.php?topic=654463.0 |
| 21:33:06 | op_mul: | there's a few of these proof of time ones. they don't seem to have any method of consensus, every node just tries to connect to every other node and measure it's uptime. |
| 21:34:15 | bramc: | op_mul, You mean proof of uptime, not proof of time? I've been talking about proofs of time, and people look at me like I've grown a second head. |
| 21:35:05 | bramc: | But proofs of time are in some sense straightforward. Proofs of uptime sound snake oily. |
| 21:35:05 | op_mul: | I can't tell you for sure because the "whitepaper" is nonsense and the code is heavily obfsucated javascript. |
| 21:35:24 | op_mul: | https://github.com/crypti/whitepaper#method-1---proof-of-time |
| 21:39:39 | bramc: | op_mul, The amount of gibberish out there is truly astounding |
| 21:40:35 | bramc: | And it's hard to argue against, because it all sounds like technical mumbo-jumbo to the general public |
| 21:41:24 | op_mul: | there's a financial incentive. |
| 21:47:30 | bramc: | The proposals for having a utxo root per block overestimate its load on the protocol. The utxo root can be generated canonically from previous transactions, so it doesn't need to be sent over the wire |
| 21:49:52 | bramc: | It isn't entirely clear what the benefits are though. Mostly so light clients can verify that a utxos hasn't been spent? |
| 21:51:58 | gmaxwell: | bramc: it would let you hot-start with SPV like security without reviewing the past state. |
| 21:53:00 | bramc: | gmaxwell, It isn't clear how much smaller the current tree is likely to be than the historical tree |
| 21:53:08 | bramc: | But fair enough |
| 21:53:12 | gmaxwell: | But maintaining a committed UTXO set is fairly expensive; (forget the bandwdith: as you note, you normally never send it.-- it's expensive because you have to keep around the interior nodes of the tree or updates all require recomputing everything; and any update has to touch log(n) interior nodes) |
| 21:53:32 | gmaxwell: | UTXO set in bitcoin is enormously smaller than the history. |
| 21:54:27 | gmaxwell: | For one, it doesn't have signatures. But unsurprisingly, coins tend to get spent. So last graph I saw of the UTXO set size looked quasi-log while block size over time looked linear. |
| 21:54:37 | gmaxwell: | Right now in bitcoin it's a ratio of about 600MB to 30GB. |
| 21:55:27 | bramc: | There's an interesting wrinkle if you assume that you want sharding and that the transaction set is so big in any one block that it needs to be sharded as well. You wind up having to put each utxos both in the position it came from and all the places it's going to and it's declared invalid if it isn't in all of them |
| 21:56:51 | bramc: | hmm, interesting. It isn't clear whether including a utxo root in each block is 'worth it' though, even for a brand new coin |
| 21:58:52 | op_mul: | gmaxwell: weeee http://statoshi.info/#dashboard/temp/oekOxR4vQf6JmgwRWhO1Xw |
| 22:01:06 | gmaxwell: | bramc: yes, it's not clear. There are also other possible commitment structures. |
| 22:02:24 | gmaxwell: | op_mul: how to lie with graps example 1231231? (non-zero x-origin) |
| 22:03:02 | op_mul: | yeah but it's the only source I know of :( |
| 22:03:04 | bramc: | gmaxwell, Perhaps not worth it purely because it's an impediment to software support |
| 22:03:38 | gmaxwell: | everything is an impediment to software. :) |
| 22:04:16 | phantomcircuit: | is there any reason to select something other than secp256k1 for a new project that needs compact signatures? |
| 22:04:37 | op_mul: | hipster cryptographer? |
| 22:04:46 | bramc: | While there's no obvious inheritance from BitTorrent to BitCoin, whoever created it seems to have absorbed the lesson of not optimizing things which don't need optimizing. |
| 22:05:21 | phantomcircuit: | op_mul, passing interest this is only at the prototype stage |
| 22:05:35 | phantomcircuit: | but once i've written it in i doubt anybody is ever going to change/question the decision |
| 22:05:39 | op_mul: | there's places satoshi really should have optimised, like not using DER encoded EC signatures. |
| 22:05:41 | phantomcircuit: | so i figured i'd ask |
| 22:06:11 | phantomcircuit: | i think the DER encoded ec signatures are actually pretty close to optimal encoding when they're actually DER and not BER |
| 22:06:21 | phantomcircuit: | iirc there's like 1 byte wasted |
| 22:06:28 | bramc: | op_mul, Okay, maybe the bencoding lesson wasn't learned |
| 22:06:34 | op_mul: | I'm not sure why they're encoded at all |
| 22:06:44 | op_mul: | the sigs are two integers |
| 22:07:08 | op_mul: | I mean, I know why they are, it's because that's what openssl gave out and satoshi treated openssl like a black box. |
| 22:08:04 | phantomcircuit: | op_mul, it's ASN.1 SEQUENCE [ INT, INT ] |
| 22:08:05 | gmaxwell: | phantomcircuit: there are 8 bytes of overhead... you could get back several of those with a lot of computation if you wanted to though. |
| 22:08:16 | gmaxwell: | (go go ASN1) |
| 22:08:24 | bramc: | A funny thing in BitTorrent history: Originally peer IPs were handing back as 'x.y.z.w', which got a bit big. Eventually people got annoyed at this and were trying to compress them and whatnot. I looked into it and found out that IP addresses are just four integers and created 'compact' encoding. Which is how it would have been done to begin with, had I know that IPs were just four integers. |
| 22:08:24 | gmaxwell: | the actual signature itself is 64 bytes exactly. |
| 22:08:45 | phantomcircuit: | oh i forgot that the sequence has it's own type |
| 22:08:49 | phantomcircuit: | er length |
| 22:09:06 | op_mul: | bramc: four? it's one 32bit integer. |
| 22:09:20 | bramc: | op_mul, It's four 8 bit integers :-) |
| 22:10:19 | phantomcircuit: | gmaxwell, iirc it's 2 bytes for the seq and then 2 bytes each for the integers |
| 22:10:20 | sipa: | it's actually a 32-bit integer |
| 22:10:26 | phantomcircuit: | where do the other 2 bytes comes from |
| 22:10:34 | sipa: | you can convert an IPv4 address in dotted quad to a single integer |
| 22:10:35 | gmaxwell: | bramc: to really blow your mind, many programs will just take a 32 bit integer (no dots) |
| 22:10:42 | sipa: | typing that integer into your browser will _work_ |
| 22:10:55 | bramc: | gmaxwell, You mean a base 10 ascii integer? |
| 22:10:59 | sipa: | yes |
| 22:11:06 | bramc: | AUGH |
| 22:11:14 | phantomcircuit: | oh im forgetting some bytes for a type delimiter arne't i |
| 22:11:18 | sipa: | http://2130706433 == localhost |
| 22:11:24 | op_mul: | bramc: https://1841923523 |
| 22:11:41 | gmaxwell: | e.g. type ping 2130706433 |
| 22:11:57 | gmaxwell: | ah I was too slow. |
| 22:12:17 | phantomcircuit: | bramc, heh |
| 22:12:32 | op_mul: | gmaxwell: 6425673729 works too :) |
| 22:12:54 | bramc: | gmaxwell, Is there a writeup somewhere of the gotchas with using heirarchical wallets with ed25519? Hopefully with fixes? |
| 22:13:35 | op_mul: | (knowing that trick is great for building filter bypasses, almost nobody knows you can make a valid URL without a single period in it) |
| 22:15:06 | phantomcircuit: | gmaxwell, no i dont think im missing any overhead |
| 22:15:39 | phantomcircuit: | there's 6 bytes of overhead |
| 22:16:36 | gmaxwell: | phantomcircuit: the largest canonical DER encoded signature is 72 bytes. The actual data is 64 bytes. You have to do some stupid 1 stuffing. |
| 22:17:34 | phantomcircuit: | ohh |
| 22:17:47 | phantomcircuit: | null byte padding to indicate signedness |
| 22:18:46 | phantomcircuit: | so mucking about with it i could definitely get a guaranteed 64 byte signature or worst case 65 bytes but with the ability to grind for shorter signatures |
| 22:19:33 | gmaxwell: | with a lot of grinding. yes. |
| 22:21:55 | phantomcircuit: | ha |
| 22:22:06 | phantomcircuit: | just took a look at petertodd'd python-bitcoinlib |
| 22:22:21 | phantomcircuit: | does signature verification by importing openssl |
| 22:22:34 | sipa: | duh |
| 22:22:48 | phantomcircuit: | was hoping to get a free pointer towards a decent library |
| 22:22:58 | phantomcircuit: | not for ceonsensus purposes |
| 22:23:02 | phantomcircuit: | consensus |
| 22:23:12 | sipa: | lol |
| 22:26:42 | gmaxwell: | optimal grinding requires somewhat tricky code, since you get a huge benefit from grinding both the nonce and the message seperately. |
| 22:27:05 | bramc: | Does this mean that bip32 is busted? http://eprint.iacr.org/2014/998 |
| 22:27:12 | gmaxwell: | e.g. you grind until you get a small r, then using that small r you grind the message until s is small. |
| 22:27:32 | gmaxwell: | Absolutely not. |
| 22:27:45 | sipa: | bramc: that vulnerability is even mentioned explicitly in the bip |
| 22:28:03 | op_mul: | didn't vitalik find it first? |
| 22:28:07 | sipa: | no |
| 22:28:24 | bramc: | What's the point of having child private keys if you can derive the master private key with them? |
| 22:28:26 | op_mul: | (sorry, meant to be a joke) |
| 22:28:27 | gmaxwell: | op_mul: I am not laughing at your shenangans. |
| 22:28:50 | gmaxwell: | bramc: This is explained in the BIP. |
| 22:29:06 | sipa: | master public keys must be treated as secret |
| 22:29:13 | gmaxwell: | BIP32 does not give you multiple _private keys_, it gives you multiple addresses. |
| 22:30:55 | gmaxwell: | And the multiple addresses are indistuishable to someone who does not know the master public key. |
| 22:31:17 | Adlai: | you mean impossible to correlate? |
| 22:31:59 | gmaxwell: | Adlai: they're indistinguishable from random. (which is a stronger criteria than impossible to coorelate) |
| 22:34:19 | bramc: | Okay, I understand the caveat that the master public key must be treated as secret. You probably should never derive it in the first place |
| 22:34:30 | op_mul: | sipa: sadly, there's people making wallets which leak the MPK to remote parties :( |
| 22:34:48 | sipa: | that's fine if you never share any private key |
| 22:34:57 | sipa: | (and most use cases do not require sharing private keys) |
| 22:35:09 | op_mul: | and if you don't mind your privavy going up the shitter. |
| 22:35:11 | sipa: | well, sharing the master pubkey also has privacy concerns |
| 22:35:15 | bramc: | How are wallets supposed to notice that a heirarchical wallet derived payment was sent to them? |
| 22:35:16 | phantomcircuit: | op_mul, lol community lore |
| 22:35:19 | phantomcircuit: | what a crock |
| 22:35:40 | sipa: | bramc: have a window a future unused derived keys, and check for transactions to them |
| 22:35:54 | gmaxwell: | phantomcircuit: I was pretty pissed when responding to their forum post and had to redraft twice. |
| 22:36:05 | phantomcircuit: | gmaxwell, i remember |
| 22:36:39 | bramc: | Is there any use at all for the master public key or is just a liability? |
| 22:36:51 | op_mul: | hardware wallets use it. |
| 22:37:07 | gmaxwell: | bramc: I really wish you'd read a bit more. |
| 22:37:11 | op_mul: | partly trusted party holds the MPK, gives unsigned transactions to a HSM to sign with the master private. |
| 22:37:14 | bramc: | op_mul, Use it how? For what? |
| 22:37:17 | gmaxwell: | The primary application the homomorphic derrivation addresses is generating new publically unlinkable unique addresses for each payment you reciever, without having to keep the spending keys online. |
| 22:37:18 | Adlai: | op_mul: the way to avoid leakage is not to derive keys from a key used to create an address, right? |
| 22:37:52 | sipa: | Adlai: you should indeed never do that |
| 22:37:54 | gmaxwell: | It's also, similarly, used for derriving more keys belonging e.g. to a hardware wallet on an online host... so you don't have to consult the hardware wallet to generate more keys constantly. |
| 22:38:14 | bramc: | gmaxwell, Sorry, I was for some reason thinking that you hand a derived private key to someone who sends you payments. Obviously that makes no sense. I'm trying to work my way through the bip, really I am |
| 22:38:40 | sipa: | there is a lot of common knowledge now that is not in the bip, because it predates it |
| 22:38:41 | gmaxwell: | bramc: ah, no, you don't hand private keys to anyone normally. |
| 22:39:10 | gmaxwell: | sipa: this is all discussed in the BIP, at least. |
| 22:39:15 | Adlai: | bramc: the use cases where child private keys are handed out are for organizations that split authority between various entities |
| 22:39:49 | Adlai: | if you have a department head with a child private key, and an auditor with the master public key, they can collude to steal funds from other departments |
| 22:40:15 | Dizzle_: | Dizzle_ is now known as Dizzle |
| 22:40:55 | bramc: | Okay, I understand now |
| 22:41:02 | gmaxwell: | Adlai: "department head with a child private key," is nonsensical. |
| 22:41:26 | Adlai: | * Adlai is referring to https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#per-office-balances-mih |
| 22:42:09 | Adlai: | maybe I misunderstood it? |
| 22:44:19 | gmaxwell: | Adlai: That example is m/iH |
| 22:46:29 | Adlai: | * Adlai schedules a reread of bip32 |
| 22:47:39 | bramc: | What is the purpose of the chain code for heirarchical wallets? |
| 22:48:17 | Adlai: | ohhhh it's a hardened key, making derivation of the parent private key impossible |
| 22:49:06 | phantomcircuit: | bramc, HD wallets are a tree not a chain |
| 22:49:29 | phantomcircuit: | that's the first thing i ask people who have implemented BIP32 btw |
| 22:49:37 | phantomcircuit: | if they say it's a chain i assume they dont have a clue |
| 22:49:41 | phantomcircuit: | (since they dont!) |
| 22:50:12 | bramc: | phantomcircuit, But doesn't the key itself allow for the derivation of later things? What would happen if you used a fixed value for the chain code every time? Obviously you use a different i to make it a tree... |
| 22:51:15 | op_mul: | phantomcircuit: there's a danger of a spec just having too many options, it means everybody just uses a subset of them |
| 22:52:03 | op_mul: | phantomcircuit: and there's some stupid risk from things like BIP38 slipping through the net and being used as a standard. that one is still incredibly annoying to me. |
| 22:53:07 | op_mul: | I've talked to lots of people that think their "encrypted" private key can be malware free or whatever because it's, you know, encrypted. end result is just people reuse addresses and ack recklessly. |
| 22:55:53 | bramc: | hmm, looks like chain code just remembers your position as a shared value between the private and public derivation because the public deriver doesn't have access to that info |
| 22:56:18 | gmaxwell: | Adlai: yep. |
| 22:56:45 | gmaxwell: | Adlai: though I'd forgotten that example was in there; it's at least specified sensibly. |
| 23:05:44 | bramc: | If I'm reading bip32 correctly, the basic trick is that if you have k1 and k2 as private keys corresponding to K1 and K2 as public keys, then (k1+k2) will have corresponding public key (K1+K2) ? |
| 23:06:05 | sipa: | yup |
| 23:06:26 | bramc: | Well that's easy. What's the caveat about ed25519? |
| 23:06:38 | sipa: | even: if you have k1 and k2 as private keys corresponding to K1 and K2 as public keys, then (a*k1 + b*k2) will have corresponding public key (a*K1 + b*K2) |
| 23:07:28 | bramc: | The derivation is basically mix i into the chain code, then generate a new key with the chain code and add that to the existing key |
| 23:08:16 | bramc: | gmaxwell, What was your problem with applying bip32 blindly to ed25519? Something about the group having a generator of size 8? |
| 23:08:18 | gmaxwell: | bramc: ed25519 implementations require the most significant bit of the private key be set. Also all ed25519 keys must be a multiple of 8. (this later criteria can be worked around in a BIP32 like formulation, the former cannot) |
| 23:09:36 | bramc: | The multiple of 8 would seem to be fixable just by multiplying by 8 |
| 23:11:14 | bramc: | gmaxwell, Is that leading bit thing referring to the high bit of the point in the curve, not some artifact of encoding? |
| 23:11:35 | sipa: | high bit of the factor multiplied with the generator |
| 23:11:39 | gmaxwell: | bramc: right; probably BIP32 should have been specified in a way that was curve neutral by saying that you had to multiply by the cofactor (which is just 1 for secp256k1, so do nothing there). In any case, the high bit set is more of a problem. |
| 23:11:47 | bramc: | And is that a deep requirement of the crypto or can you just break the implementation to not require that any more? |
| 23:12:02 | gmaxwell: | You could break the implementation but then be randomly incompatible. |
| 23:12:57 | bramc: | So the high bit thing is a defense against weak keys? |
| 23:13:02 | gmaxwell: | And once you're in the realm of not being able to use a high quality standard implementations you start running out of advantages for a different curve. |
| 23:13:27 | sipa: | it's necessary for constant-timeness of their signing algorithm, i believe? |
| 23:13:30 | sipa: | unsure |
| 23:13:32 | andytoshi: | bramc: i think it's about timing |
| 23:14:17 | andytoshi: | iirc djb hinted at this but wasn't very clear in the curve25519 paper, and there isn't any other justification |
| 23:14:23 | gmaxwell: | IIRC it's because their 'complete' addition formula can't handle the point at infinity. So their multiply ladder can always start with a 1 instead of a zero so long as the high bit must be set. |
| 23:15:06 | gmaxwell: | If so it could be worked around at the expense of slowing down the code by adding more cmovs. |
| 23:15:15 | gmaxwell: | (and tracking an infinity flag) |
| 23:15:21 | gmaxwell: | Which is what we do in libsecp256k1. |
| 23:15:51 | andytoshi: | nsh: iirc you emailed djb about this? did you get a reply? |
| 23:16:19 | gmaxwell: | But if you can't you high quality standard code; it greatly reduces any advantage in one curve vs another. |
| 23:16:52 | gmaxwell: | since a lot of the motivation for parameters is tyed up in implementation quality. |
| 23:16:55 | bramc: | I mailed djb about a few things recently and haven't heard back on any of them |
| 23:17:28 | ajweiss: | for faster service, include qmail bug |
| 23:17:46 | sipa: | lol |
| 23:18:05 | nsh: | andytoshi, might have been more of an intention than a thing-wot-i-then-actually-done-did |
| 23:18:19 | nsh: | i meant to hassle him about a bunch of stuff at congress too, and he evaded me |
| 23:18:45 | nsh: | (by sneakily scheduling ECCHacks for when i was distracted/asleep/ondrugs/elsewhere) |
| 23:18:55 | gmaxwell: | well he'll respond to me if I email him (has the last several times at least) but if you're just curious about this it's easier to just read the code. |
| 23:19:54 | deego: | http://www.unbreakablecoin.com/ looky! It's unbreakable! Says right there in its name. Let's switch! |
| 23:19:56 | bramc: | gmaxwell, the 'why' of something like the high bit can be rather hard to ascertain from the code, particularly security-heavy crypto code |
| 23:20:33 | bramc: | It could be that the last mail I sent to djb suffered from containing much too open-ended and interesting questions and he didn't have the cycles to spare on it |
| 23:20:52 | gmaxwell: | bramc: Well it's pretty clear if it does what I suggested it does above: e.g. does it initilize the ladder with 1 instead of infinity and skip the first bit; and does the addition formula have code to handle the accumulator argument being infinity. |
| 23:21:14 | deego: | (It's twice as fast, and four times the size of this puny, slow bitcoin!) |
| 23:21:17 | gmaxwell: | If not than regardless of what the motivations were, at a minimum that would have to change. |
| 23:21:51 | bramc: | gmaxwell, I have no idea how that affects timing, and you're getting much deeper into the math than I remember off the top of my head |
| 23:21:59 | op_mul: | deego: that's a 504. |
| 23:22:32 | gmaxwell: | And annoyingly that would be incompatible (inside crypto inner loops). At which point "why use this over secp256k1?" is a more serious question? |
| 23:22:43 | deego: | op_mul: probably because the "creator" has managed to get himself slashdotted. |
| 23:22:56 | deego: | (did he pay dice for the advertizement?) |
| 23:23:01 | sipa: | bramc: in an exponentiation ladder with one guaranteed bit set, you can trivially avoid having any internal result being the point at infinity |
| 23:23:12 | gmaxwell: | yea, I saw that and went "hm. guess slashdot takes paid placement now." |
| 23:23:25 | sipa: | bramc: which means slightly faster/less code |
| 23:23:25 | deego: | ikr |
| 23:23:34 | op_mul: | deego: unbreakable is about as ominous as unsinkable. |
| 23:23:59 | bramc: | gmaxwell, The main motivation is it's schnorr, I guess you could use schnorr with secp256k1 |
| 23:23:59 | andytoshi: | i think gmaxwell is right, in fe25519.c `static void reduce_add_sub(fe25519 *r)` we see exactly what he described ... ladder initialized with high bit set then a loop that skips it |
| 23:24:02 | deego: | op_mul: haha |
| 23:24:16 | sipa: | bramc: as otherwise you need a branch to check whether your addition would result in infinity (or use the conditional move trick, basically executing both branches and only using the result of the one you need) |
| 23:24:20 | andytoshi: | (in the supercop reference impl, not the optimized one) |
| 23:24:33 | andytoshi: | and no branching |
| 23:24:42 | gmaxwell: | bramc: and indeed there is an implementation in the libsecp256k1 github; though it hasn't been updated lately. |
| 23:25:04 | op_mul: | er. why is this "unbreakable coin" misusing bluematt's real name? |
| 23:25:27 | sipa: | op_mul: where? |
| 23:25:35 | op_mul: | https://github.com/jimblasko/UnbreakableCoin-master/commit/21695a61e000f6b2759626e2097c68573e1447cf |
| 23:26:25 | gmaxwell: | wut |
| 23:26:29 | gmaxwell: | BlueMatt: ?! |
| 23:26:36 | deego: | (also, wc. sorry, I thought I was talking in #bitcoin.) |
| 23:26:57 | op_mul: | OH |
| 23:27:01 | op_mul: | it's a coingen coin |
| 23:27:04 | gmaxwell: | lol may be due to coingen! |
| 23:27:04 | gmaxwell: | lol |
| 23:27:15 | gmaxwell: | it's a coingen altcoin? hahah |
| 23:27:21 | op_mul: | From: Matt Corallo |
| 23:27:51 | sipa: | it's not just a coingen altcoin! |
| 23:28:01 | sipa: | it also has a patch to chmod a leveldb script file! |
| 23:28:12 | sipa: | and some artwork changes |
| 23:28:20 | gmaxwell: | Did they add a dog? |
| 23:29:03 | op_mul: | I can't confirm any dog at this point in time. |
| 23:29:24 | sipa: | also this readme line change: |
| 23:29:26 | sipa: | Unbreakablecoin is based on Bitcoin's core with modifications to it's speed and size. |
| 23:29:34 | sipa: | (find the grammar error) |
| 23:29:35 | gmaxwell: | andytoshi: hurray, my memory isn't completely worthless. |
| 23:29:45 | justanotheruser: | sipa: their paint is thicker, rendering it unbreakable |
| 23:29:57 | sipa: | leaded paint |
| 23:30:26 | justanotheruser: | Bitcoin's core? |
| 23:31:02 | bramc: | Okay, really really stupid question: Schnorr works with any curve, right? Including secp256k1? |
| 23:31:10 | andytoshi: | gmaxwell: did you notice this as part of secp256k1 work or was it actually mentioned in the curve25519 paper? |
| 23:32:01 | andytoshi: | i remember specifically looking for an explanation in there, i'm disappointed to know that i missed it (tho at the time i know i didn't understand the ladder stuff and probably skipped it) |
| 23:32:12 | sipa: | bramc: yes |
| 23:32:19 | sipa: | well, "any" is a very large set |
| 23:32:23 | sipa: | but typical |
| 23:32:37 | andytoshi: | bramc: schnorr is group-agnostic, you only need discrete log to be hard |
| 23:32:43 | sipa: | bramc: there's a pull request to to add schnorr to libsecp256k1 |
| 23:33:08 | sipa: | it's outdated now, and we probably want to do things a bit differently now |
| 23:33:13 | sipa: | but it would work |
| 23:33:41 | gmaxwell: | andytoshi: no; so I had read that code a while back (to see if it did anything useful we should do for libsecp256k1) but didn't actually notice that. I knew from the ed25519 writeup they required the bit set; I only connected why while typing in here a moment ago (part of why I wasn't sure) |
| 23:34:20 | gmaxwell: | So weird (but also so DJB) to gum up the works with a speed hack basically to avoid one line of code https://github.com/bitcoin/secp256k1/blob/master/src/group_impl.h#L361 but perhaps for his addition law it's somehow more complex than that. |
| 23:34:27 | op_mul: | I saw some comments about making a libsecp256k low memory mode, how serious of a plan was that? :) |
| 23:34:48 | bramc: | sipa, It has merge conflicts now? https://github.com/bitcoin/secp256k1/pull/87 |
| 23:34:54 | gmaxwell: | op_mul: its a few minutes hacking basically. |
| 23:34:55 | sipa: | bramc: as i said, it's outdated |
| 23:35:00 | sipa: | bramc: but the old code worked |
| 23:35:41 | op_mul: | gmaxwell: to get it down to < 20kB |
| 23:36:03 | sipa: | code size? ram size? rom size? |
| 23:36:08 | op_mul: | memory |
| 23:36:13 | sipa: | including what? |
| 23:36:34 | bramc: | gmaxwell, It might have to do with time invariance |
| 23:36:38 | gmaxwell: | signing only? |
| 23:36:42 | BlueMatt: | op_mul: gmaxwell lol, sooooo old shit |
| 23:36:51 | BlueMatt: | coingen hasnt run in.....who knows how long? |
| 23:36:52 | sipa: | bramc: yes, it does |
| 23:37:03 | sipa: | bramc: it avoids a branch |
| 23:37:07 | op_mul: | sipa: gmaxwell: signing ideally. \ |
| 23:37:25 | op_mul: | BlueMatt: sorry for bothing you, should have thought for a few minutes before bringing it up |
| 23:37:35 | sipa: | op_mul: 20 kB including what? code / static data / ram? |
| 23:37:51 | BlueMatt: | op_mul: lol, np |
| 23:38:07 | sipa: | if a 1 MB precomputed table is acceptable, it may be good already |
| 23:38:56 | op_mul: | sipa: limits are 120kB-ish for the flash, 20kB for the memory |
| 23:39:43 | op_mul: | actually, I could stop being cheap and just buy one with 2KB of flash |
| 23:39:46 | bramc: | Looks like ed25519 is about twice as fast http://justmoon.github.io/curvebench/benchmark.html |
| 23:40:13 | gmaxwell: | lol no. |
| 23:40:19 | gmaxwell: | Thats year old stuff. |
| 23:40:23 | sipa: | bramc: look at the pullreqs for that repo |
| 23:40:29 | sipa: | i submitted updated benchmarks |
| 23:40:36 | sipa: | which are outdated now too |
| 23:40:50 | gmaxwell: | (also it was misconfigured because it rupped out the buildsystem) |
| 23:41:22 | op_mul: | ah, damn, there's no 2KB flash version. limit seems to be 1KB. |
| 23:41:49 | gmaxwell: | ripped* |
| 23:42:01 | bramc: | sipa, How does it do with the updated benchmark? |
| 23:42:54 | sipa: | with the endomorphism optimization (which may be patented) and libgmp (which you may not want to rely on in consensus-critical code), it's over 10% faster than ed25519 for non-batch verification |
| 23:43:12 | op_mul: | gmaxwell: ha, how's this. the model the trezor is using can come with a crypto coprocessor that can do all the things the trezor doesn't need to do. got us some DES, TDEA, AES, SHA1 and MD5. how handy! |
| 23:43:25 | sipa: | with some pullreqs that are not merged yet, it's closer to 20% faster |
| 23:43:52 | bramc: | sipa, What's wrong with libgmp? |
| 23:43:58 | sipa: | more code |
| 23:44:02 | kanzure: | surface area |
| 23:44:29 | sipa: | and consensus-critical systems have much stronger requirements than typical projects |
| 23:44:39 | sipa: | as in: fixing a bug may not be wanted |
| 23:44:41 | gmaxwell: | GMP has never promised to not fix bugs. |
| 23:44:43 | gmaxwell: | :) |
| 23:45:15 | op_mul: | gmaxwell: and it has a hardware RNG. neat. |
| 23:45:47 | sipa: | i trust GMP does a good job of testing and having few bugs in general, but that's not always enough |
| 23:45:58 | bramc: | Okay, I'm sold on the bitcoin curve |
| 23:49:58 | op_mul: | o.o tamper detection? |
| 23:52:31 | op_mul: | right. battery backed SRAM, 80 bytes. |
| 23:53:04 | op_mul: | enough for a BIP32 key if you felt like living dangerously. |
| 23:55:20 | bramc: | sipa, When you say you'd do it differently now for that pull request, are you referring to the encoding used or the code layout? |