00:02:26rusty:op_mul: A BIP might be overkill, but gathering wallet privacy "best practice" in one place might be a start?
00:05:30bramc:By compressed keys, you means one where the secure hash is given?
00:06:30op_mul:no. EC points can be "compressed" by just showing the sign of Y rather than the whole integer.
00:07:14rusty:bramc: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
00:07:47bramc:Oh right. That would seem to be a ridiculous no-brainer
00:08:08op_mul:up until recently the majority of all signatures were from non-compressed point keys.
00:09:19rusty: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:48op_mul:it's supported in core since like 2011
00:13:06rusty:op_mul: hey, that's only 4 years, don't rush us!
00:14:05op_mul:rusty: https://github.com/blockchain/My-Wallet/commit/1c04bef8fe2afb5f20035067d42a2277cdef82cb#diff-f3aa2b02abfd24669b81e0d6a8f54557R722
00:15:14phantomcircuit:ha it's literally like 8 lines
00:16:18rusty:phantomcircuit: sure, but that's changing the default, not supporting them in the first place.
00:16:31op_mul:their library supported it since 2011.
00:17:09op_mul:you see, users panic when they export their private keys and it doesn't begin with a 5
00:17:14gmaxwell:op_mul: likely since the day it was written.
00:17:18gmaxwell:there is basically nothing to do to support it in most software.
00:18:41op_mul:yes. you can see why I don't think there's any use bugging wallet devs about minor privacy quirks.
00:19:39rusty:op_mul: no, you want their users to do that. Which means that they have to know about it...
00:22:03op_mul:rusty: I think I would have a hard time convincing people to be upset about it.
00:24:07rusty:op_mul: I believe the way modern kids do it is to register www.areweprivateyet.com, which takes a txid.
00:28:34op_mul:rusty: I have no intention of putting myself at risk for the sake of other peoples privacy.
00:57:58bramc:op_mul, I would hope that most bitcoin users aren't posting about their transactions to bitcointalk and reddit
00:58:25op_mul:bramc: you'd be surprised.
00:58:45bramc:That doesn't bode well for the total number of bitcoin users or how mainstream they are
01:00:05op_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:02bramc:That sounds likely. There's a lack of actual commerce one can point to getting enabled by bitcoin
01:08:23bramc:And the price differences on the exchanges indicate sky-high counterparty risk
01:13:55bramc: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:11op_mul:bramc: I don't imagine it will be for a long time
01:19:55bramc:It's roughly a factor of 5 off right now
01:41:26petertodd:bramc: wtf do you think colored coins will give a damn about tx costs?
01:42:09petertodd: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:51bramc: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:21bramc:And why are you cursing at me? I've been making mild comments and you've been going into a rage.
01:43:44petertodd:bramc: huh? the "nominal value" has nothing to do with the value of the asset being moved
01:44:01petertodd:bramc: and don't think this is a "rage" - I'm just incredibly confused how you would think that
01:44:31bramc: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:55petertodd:no, the costs in terms of real value are identical
01:45:36bramc: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:43petertodd: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:56petertodd:s/pound/kilogram/ lol
01:46:19bramc:But you need to get those satoshis from somewhere to do the transfer, and you don't have it
01:47:16petertodd:what's hard about just exchanging some gold for bitcoin?
01:47:33bramc: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:56bramc:It looks kind of weird if colored coin transactions are almost entirely transaction fees
01:48:17pigeons:? isnt the point that they are almost entirely transaction fees
01:48:26phantomcircuit:bramc, they correctly support that specifically because of the transaction fees issue
01:48:41bramc:Oh, okay, it won't be that much of a change then I guess
01:49:16petertodd: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:27petertodd: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:29bramc:Well, you could pool together a bunch of transactions to a single hash root...
01:50:54phantomcircuit: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:57petertodd:bramc: exactly, I'll be getting around to implementing exactly that at some point
01:51:24phantomcircuit: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:30bramc:Ah, I see your point now. Twitter is a lousy medium for having a discussion.
01:51:34petertodd: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:12phantomcircuit:petertodd, sure but then you need to incentivize people not to withhold
01:52:21petertodd: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:49petertodd: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:42petertodd:to force whitelits to have users give up thier private keys, make part of commitment in S1 be the private key itself
01:57:38petertodd: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:58petertodd:*to force censorship to have
02:00:48bramc:petertodd, Do you have a link explaining this? I'd like to spend some time thinking through it later?
02:00:57justanotheruser: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:49petertodd:bramc: haven't written this up properly yet; writing software to do this
02:02:54petertodd: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:12phantomcircuit: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:34kanzure: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:02kanzure:i don't have a good sense for what percent of audit events haven't had appropriate cryptography identified yet
02:09:52kanzure: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:01justanotheruser: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:05phantomcircuit:kanzure, my first guess would be approximately 0% have had sound cryptography applied to them
02:10:07justanotheruser:... there something I'm missing?
02:10:21kanzure:phantomcircuit: not what i meant, although yes i agree
02:10:43phantomcircuit:justanotheruser, the issuer can be financial secure but technically incompetent
02:10:59kanzure: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:06phantomcircuit:which is indeed the most common situation
02:11:37justanotheruser: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:53bramc:petertodd, Maybe there should be an OP_VERIFY_COLORED_SIDECHAIN
02:12:08justanotheruser:bramc: I don't see why there would need to be a separate opcode
02:12:20bramc:justanotheruser, So you could peg
02:12:24justanotheruser:(separate from OP_SIDECHAIN_VERIFY or whatever its called)
02:12:44phantomcircuit:justanotheruser, there's no reason that a system using bitcoin for ordering couldn't replace bitcoin with another chain
02:13:07justanotheruser:phantomcircuit: did I imply otherwise?
02:13:35kanzure:cross-organization audits can be assisted by public crypto auditing stuff
02:13:44kanzure:for example, maybe your audit only passes if all your suppliers are also passing
02:14:14phantomcircuit: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:30kanzure: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:56kanzure:*fraud proofs to redeem posted bond amounts... someone suggested this i dunno who.
02:20:17starsoccer:starsoccer is now known as Guest48951
02:22:02justanotheruser: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:08justanotheruser:... 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:23justanotheruser:excuse my difficult to read english.
02:24:09phantomcircuit: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:31phantomcircuit:as i said before these are rare to find in one place
02:27:32justanotheruser:The incentives for getting transaction fees is pretty high.
02:27:59phantomcircuit:justanotheruser, transaction fees in normal financial systems are typically too small to care about
02:28:09phantomcircuit:except for payment card systems
02:28:15phantomcircuit:those are lulz worthy
02:29:41phantomcircuit:justanotheruser, for example the fee that your bank charges for electronic ach payments is entirely meaningless to them
02:29:57phantomcircuit:for evidence of this look at what they charge you to handle paper checks: $0.00
02:30:11justanotheruser:phantomcircuit: I assume it is an anti-DoS feature?
02:30:32justanotheruser:err wrong word
02:30:40justanotheruser:I assume it is just so it is costly for me to abuse it
02:31:09phantomcircuit:justanotheruser, i think it was just a "because we can and fuck you" type fee
02:31:41phantomcircuit: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:06bramc: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:07phantomcircuit:iirc an ACH transaction costs them something like $0.000045
02:32:12justanotheruser: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:43phantomcircuit: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:44bramc:Using the bitcoin blockchain reduces the changes that an alt network will die from disinterest
02:32:59bramc:phantomcircuit, no the banks make good money off of them
02:33:21phantomcircuit:bramc, i kind of doubt it actually
02:33:33justanotheruser: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:52justanotheruser:how often do you exchange promises of assets and how often do you exchange money
02:35:07phantomcircuit:bramc, the interesting question is what % of revenues they represent, im guessing it's < 1%
02:36:01bramc:phantomcircuit, Probably depends on whether you look at the financial institution as a whole or just the retail banking part
02:36:38bramc: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:56justanotheruser: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:04phantomcircuit:of they could you know... just have overdraft turned off
02:38:05bramc: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:39justanotheruser:if you don't want to go into debt, don't sign a contract that allows it :/
02:38:58bramc: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:27justanotheruser:bramc: you sure there is a legislative limit?
02:39:40justanotheruser:that seems silly, market forces could easily drive out someone charging too much
02:40:11bramc:No it's a natural monopoly, they mostly have to avoid becoming a regulated entity
02:40:14phantomcircuit:bramc, iirc it's only debit cards that have legislated limits
02:40:36phantomcircuit:maybe not
02:40:38justanotheruser:monopoly? theres visa, mastercard, discover, american express...
02:41:03bramc: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:31bramc:discover and especially american express are rejected at a lot of places
02:42:25justanotheruser: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:27bramc: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:53bramc:And then of course there are some cards with cash-back bonuses. Blech.
02:42:55justanotheruser:then businesses would start taking cash
02:43:11bramc:There's a reason why most businesses still happily take cash
02:43:17MRL-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:43bramc:Who and where just said that?
02:43:47justanotheruser:I don't think regulation of credit cards are necessary when there is already a free alternative
02:44:04justanotheruser:I have an "othe" in my name?
02:44:36bramc: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:13starsoccer:starsoccer is now known as Guest54312
03:50:52contrapumpkin:contrapumpkin is now known as copumpkin
04:34:01Guest54312:Guest54312 is now known as starsoccer
04:34:30fanquake_:fanquake_ is now known as fanquake
05:45:18_Plebington_:_Plebington_ has left #bitcoin-wizards
06:35:12lclc:lclc is now known as lclc_bnc
07:59:53phantomcircuit:bramc, vendors are now free to price discriminate based on payment method
08:00:48bramc: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:47phantomcircuit:bramc, visa/mastercard has lost a string of antitrust cases many of which went to the supreme court
08:03:03bramc:Oh good, that cheers me up
08:03:14bramc:Sanity prevails
09:05:13card.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:13card.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:13card.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:13card.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:13card.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:55hearn:hearn is now known as hearn[lunch]
13:22:32lclc_bnc:lclc_bnc is now known as lclc
13:31:02hearn[lunch]:hearn[lunch] is now known as hearn
14:15:54gmaxwell:gmaxwell is now known as Guest23941
14:50:46Guest23941:Guest23941 is now known as gmaxwell
15:04:55lclc:lclc is now known as lclc_bnc
15:10:18lclc_bnc:lclc_bnc is now known as lclc
15:44:36justanot1eruser:justanot1eruser is now known as justanotheruser
15:53:21amiller:andytoshi, i can't figure out why your ringsig-blinding is supposed to work
15:53:56amiller: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:29amiller: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:42amiller:but can't they still prove that their key image isn't the key image that was spent?
15:57:10amiller: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:53amiller:er I = x H(P_actual)
15:58:16amiller:so, if you save your 'x', you can prove you weren't involved later on
15:58:47amiller:for posterity, this comment refers to https://download.wpsoftware.net/bitcoin/wizardry/ringsig-blinding.txt which is dated sep'14
15:59:58gmaxwell:Yes, but you must do that at the time of signing.
16:00:10gmaxwell:And in particular if you weren't involved you can't prove you weren't involved.
16:01:15amiller:gmaxwell, suppose the real coin is P1 and I owned the coin P2....
16:01:38amiller: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:41gmaxwell:(this scheme itself is not so useful for cryptocurrency usage, so talking about coins isn't so great)
16:02:08amiller:alright swap public key for coin
16:02:12gmaxwell:(because it breaks the ability to use the key images to prevent double spending. It's useful for voting like schemes)
16:02:57amiller:maybe this has abolutely nothing to do with cryptonote and i totally misunderstood the intended application of this.
16:04:11gmaxwell: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:31gmaxwell:(and obviously not me either; so we can all plausably deny authorship.)
16:04:43amiller: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:56gmaxwell:There is a thing related to cryptonode that andytoshi and I were working on. ... yea that thing.
16:07:06gmaxwell: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:52zooko:zooko has left #bitcoin-wizards
16:21:41lclc:lclc is now known as lclc_bnc
17:09:40andytoshi: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:00andytoshi:it is also possible to just reveal your x, and there is no way to block that
17:11:16andytoshi: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:52andytoshi:one moment actually, i don't remember how much gmaxwell's blinding scheme does :)
17:12:56andytoshi:oh wait, i'm being stupid, i'm talking about something else entirely, ignore me
17:13:50andytoshi:same hallucination as amiller. must be some andrew-targeting chemical agent out there..
18:04:53samson2:samson2 is now known as samson_
18:55:37gmaxwell:andytoshi: well I didn't remember it either, I went and read the thing amiller linked to before commenting.
19:12:27andytoshi: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:20fluffypony:apparently secp256k1 doesn't meet all of the SafeCurve requirements
19:19:28gmaxwell: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:57gmaxwell:(which has resulted in completely broken protocols several times in the past, e.g. PAKE schemes.)
19:20:56fluffypony:sure, I just didn't realise DJB had a curves page until now
19:34:29gmaxwell:fluffypony: I'd commented on it at some depth at https://bitcointalk.org/index.php?topic=380482.msg4082496#msg4082496
19:35:13phantomcircuit:i do like his domain name though
19:35:17phantomcircuit:that's super clever
19:36:11fluffypony:well it is DJB, pretty sure he was given that domain before the Internet even existed (I kid)
19:58:25lclc_bnc:lclc_bnc is now known as lclc
20:04:47lclc:lclc is now known as lclc_bnc
20:56:06earlz:Have there been any significant "wishlist" type things for a transaction v2 format or some such?
20:56:31earlz:I've seen one proposal to make it so everything is effectively p2sh (ie, there is no output script, just a scripthash)
20:56:43earlz:but other than that nothing
20:57:53andytoshi:earlz: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas https://en.bitcoin.it/wiki/Hardfork_Wishlist
20:58:05andytoshi:the latter is not on bitcoin.ninja, i will submit a pr..
20:59:06earlz:yea, I've seen the hardfork wishlist, but nothing in there covering transactions
21:12:45bramc:earlz, schnorr-based signatures, to allow collaborative signature generation
21:14:32earlz:schnorr.. not heard of that one. I'll have to look it up
21:14:45earlz:do you have a reference for how it applies to bitcoin?
21:16:00andytoshi: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:39bramc:The main schnorr contender is ed25519. Perhaps the only serious contender.
21:16:41andytoshi: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:54bramc:andytoshi, And it allows collaborative signature generation!
21:18:09earlz:Has there been any practical proof that ecdsa could possibly have multiple valid signatures? (ie, transaction malleability)
21:18:17andytoshi:bramc: oh, right, that's a big one!
21:18:27earlz:what do you mean collaborative?
21:18:49andytoshi: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:06bramc: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:24earlz:what benefit does that bring over multisig?
21:19:31andytoshi: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:32bramc:It allows the transactions to be smaller and less identifiable
21:19:47andytoshi:earlz: then you get a single signature that cannot be distinguished from a boring old 1-of-1
21:20:43earlz:hmm interesting
21:21:09earlz:is that scheme at all proved secure? or is it relatively new?
21:22:14andytoshi: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:33earlz:well, I mean like peer-reviewed and all that
21:23:48earlz:I'm not super knowledgable about how crypto works at that low of alevel
21:23:55andytoshi:does folklore count as peer review? :P
21:24:47andytoshi: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:43bramc: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:47op_mul:bramc: there's some shitcoins using it.
21:29:02tromp:so clearly not every shitcoin component is shitty
21:29:30op_mul:bramc: here you go, here's some nutty anti-science and es25519 https://bitcointalk.org/index.php?topic=881427.0
21:29:46op_mul:it uses 64 bit timestamps! 320 bit hashes!
21:30:57tromp:shockingly, it doesn't claim to be "super-secure"
21:31:18tromp:i mean super-sekure :-)
21:32:16op_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:06op_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:15bramc: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:05bramc:But proofs of time are in some sense straightforward. Proofs of uptime sound snake oily.
21:35:05op_mul:I can't tell you for sure because the "whitepaper" is nonsense and the code is heavily obfsucated javascript.
21:39:39bramc:op_mul, The amount of gibberish out there is truly astounding
21:40:35bramc:And it's hard to argue against, because it all sounds like technical mumbo-jumbo to the general public
21:41:24op_mul:there's a financial incentive.
21:47:30bramc: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:52bramc: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:58gmaxwell:bramc: it would let you hot-start with SPV like security without reviewing the past state.
21:53:00bramc:gmaxwell, It isn't clear how much smaller the current tree is likely to be than the historical tree
21:53:08bramc:But fair enough
21:53:12gmaxwell: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:32gmaxwell:UTXO set in bitcoin is enormously smaller than the history.
21:54:27gmaxwell: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:37gmaxwell:Right now in bitcoin it's a ratio of about 600MB to 30GB.
21:55:27bramc: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:51bramc: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:52op_mul:gmaxwell: weeee http://statoshi.info/#dashboard/temp/oekOxR4vQf6JmgwRWhO1Xw
22:01:06gmaxwell:bramc: yes, it's not clear. There are also other possible commitment structures.
22:02:24gmaxwell:op_mul: how to lie with graps example 1231231? (non-zero x-origin)
22:03:02op_mul:yeah but it's the only source I know of :(
22:03:04bramc:gmaxwell, Perhaps not worth it purely because it's an impediment to software support
22:03:38gmaxwell:everything is an impediment to software. :)
22:04:16phantomcircuit:is there any reason to select something other than secp256k1 for a new project that needs compact signatures?
22:04:37op_mul:hipster cryptographer?
22:04:46bramc: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:21phantomcircuit:op_mul, passing interest this is only at the prototype stage
22:05:35phantomcircuit:but once i've written it in i doubt anybody is ever going to change/question the decision
22:05:39op_mul:there's places satoshi really should have optimised, like not using DER encoded EC signatures.
22:05:41phantomcircuit:so i figured i'd ask
22:06:11phantomcircuit:i think the DER encoded ec signatures are actually pretty close to optimal encoding when they're actually DER and not BER
22:06:21phantomcircuit:iirc there's like 1 byte wasted
22:06:28bramc:op_mul, Okay, maybe the bencoding lesson wasn't learned
22:06:34op_mul:I'm not sure why they're encoded at all
22:06:44op_mul:the sigs are two integers
22:07:08op_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:04phantomcircuit:op_mul, it's ASN.1 SEQUENCE [ INT, INT ]
22:08:05gmaxwell: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:16gmaxwell:(go go ASN1)
22:08:24bramc: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:24gmaxwell:the actual signature itself is 64 bytes exactly.
22:08:45phantomcircuit:oh i forgot that the sequence has it's own type
22:08:49phantomcircuit:er length
22:09:06op_mul:bramc: four? it's one 32bit integer.
22:09:20bramc:op_mul, It's four 8 bit integers :-)
22:10:19phantomcircuit:gmaxwell, iirc it's 2 bytes for the seq and then 2 bytes each for the integers
22:10:20sipa:it's actually a 32-bit integer
22:10:26phantomcircuit:where do the other 2 bytes comes from
22:10:34sipa:you can convert an IPv4 address in dotted quad to a single integer
22:10:35gmaxwell:bramc: to really blow your mind, many programs will just take a 32 bit integer (no dots)
22:10:42sipa:typing that integer into your browser will _work_
22:10:55bramc:gmaxwell, You mean a base 10 ascii integer?
22:11:14phantomcircuit:oh im forgetting some bytes for a type delimiter arne't i
22:11:18sipa:http://2130706433 == localhost
22:11:24op_mul:bramc: https://1841923523
22:11:41gmaxwell:e.g. type ping 2130706433
22:11:57gmaxwell:ah I was too slow.
22:12:17phantomcircuit:bramc, heh
22:12:32op_mul:gmaxwell: 6425673729 works too :)
22:12:54bramc:gmaxwell, Is there a writeup somewhere of the gotchas with using heirarchical wallets with ed25519? Hopefully with fixes?
22:13:35op_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:06phantomcircuit:gmaxwell, no i dont think im missing any overhead
22:15:39phantomcircuit:there's 6 bytes of overhead
22:16:36gmaxwell: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:47phantomcircuit:null byte padding to indicate signedness
22:18:46phantomcircuit: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:33gmaxwell:with a lot of grinding. yes.
22:22:06phantomcircuit:just took a look at petertodd'd python-bitcoinlib
22:22:21phantomcircuit:does signature verification by importing openssl
22:22:48phantomcircuit:was hoping to get a free pointer towards a decent library
22:22:58phantomcircuit:not for ceonsensus purposes
22:26:42gmaxwell:optimal grinding requires somewhat tricky code, since you get a huge benefit from grinding both the nonce and the message seperately.
22:27:05bramc:Does this mean that bip32 is busted? http://eprint.iacr.org/2014/998
22:27:12gmaxwell: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:32gmaxwell:Absolutely not.
22:27:45sipa:bramc: that vulnerability is even mentioned explicitly in the bip
22:28:03op_mul:didn't vitalik find it first?
22:28:24bramc:What's the point of having child private keys if you can derive the master private key with them?
22:28:26op_mul:(sorry, meant to be a joke)
22:28:27gmaxwell:op_mul: I am not laughing at your shenangans.
22:28:50gmaxwell:bramc: This is explained in the BIP.
22:29:06sipa:master public keys must be treated as secret
22:29:13gmaxwell:BIP32 does not give you multiple _private keys_, it gives you multiple addresses.
22:30:55gmaxwell:And the multiple addresses are indistuishable to someone who does not know the master public key.
22:31:17Adlai:you mean impossible to correlate?
22:31:59gmaxwell:Adlai: they're indistinguishable from random. (which is a stronger criteria than impossible to coorelate)
22:34:19bramc: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:30op_mul:sipa: sadly, there's people making wallets which leak the MPK to remote parties :(
22:34:48sipa:that's fine if you never share any private key
22:34:57sipa:(and most use cases do not require sharing private keys)
22:35:09op_mul:and if you don't mind your privavy going up the shitter.
22:35:11sipa:well, sharing the master pubkey also has privacy concerns
22:35:15bramc:How are wallets supposed to notice that a heirarchical wallet derived payment was sent to them?
22:35:16phantomcircuit:op_mul, lol community lore
22:35:19phantomcircuit:what a crock
22:35:40sipa:bramc: have a window a future unused derived keys, and check for transactions to them
22:35:54gmaxwell:phantomcircuit: I was pretty pissed when responding to their forum post and had to redraft twice.
22:36:05phantomcircuit:gmaxwell, i remember
22:36:39bramc:Is there any use at all for the master public key or is just a liability?
22:36:51op_mul:hardware wallets use it.
22:37:07gmaxwell:bramc: I really wish you'd read a bit more.
22:37:11op_mul:partly trusted party holds the MPK, gives unsigned transactions to a HSM to sign with the master private.
22:37:14bramc:op_mul, Use it how? For what?
22:37:17gmaxwell: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:18Adlai:op_mul: the way to avoid leakage is not to derive keys from a key used to create an address, right?
22:37:52sipa:Adlai: you should indeed never do that
22:37:54gmaxwell: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:14bramc: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:40sipa:there is a lot of common knowledge now that is not in the bip, because it predates it
22:38:41gmaxwell:bramc: ah, no, you don't hand private keys to anyone normally.
22:39:10gmaxwell:sipa: this is all discussed in the BIP, at least.
22:39:15Adlai:bramc: the use cases where child private keys are handed out are for organizations that split authority between various entities
22:39:49Adlai: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:15Dizzle_:Dizzle_ is now known as Dizzle
22:40:55bramc:Okay, I understand now
22:41:02gmaxwell:Adlai: "department head with a child private key," is nonsensical.
22:41:26Adlai:* Adlai is referring to https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#per-office-balances-mih
22:42:09Adlai:maybe I misunderstood it?
22:44:19gmaxwell:Adlai: That example is m/iH
22:46:29Adlai:* Adlai schedules a reread of bip32
22:47:39bramc:What is the purpose of the chain code for heirarchical wallets?
22:48:17Adlai:ohhhh it's a hardened key, making derivation of the parent private key impossible
22:49:06phantomcircuit:bramc, HD wallets are a tree not a chain
22:49:29phantomcircuit:that's the first thing i ask people who have implemented BIP32 btw
22:49:37phantomcircuit:if they say it's a chain i assume they dont have a clue
22:49:41phantomcircuit:(since they dont!)
22:50:12bramc: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:15op_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:03op_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:07op_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:53bramc: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:18gmaxwell:Adlai: yep.
22:56:45gmaxwell:Adlai: though I'd forgotten that example was in there; it's at least specified sensibly.
23:05:44bramc: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:26bramc:Well that's easy. What's the caveat about ed25519?
23:06:38sipa: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:28bramc: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:16bramc:gmaxwell, What was your problem with applying bip32 blindly to ed25519? Something about the group having a generator of size 8?
23:08:18gmaxwell: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:36bramc:The multiple of 8 would seem to be fixable just by multiplying by 8
23:11:14bramc:gmaxwell, Is that leading bit thing referring to the high bit of the point in the curve, not some artifact of encoding?
23:11:35sipa:high bit of the factor multiplied with the generator
23:11:39gmaxwell: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:47bramc:And is that a deep requirement of the crypto or can you just break the implementation to not require that any more?
23:12:02gmaxwell:You could break the implementation but then be randomly incompatible.
23:12:57bramc:So the high bit thing is a defense against weak keys?
23:13:02gmaxwell: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:27sipa:it's necessary for constant-timeness of their signing algorithm, i believe?
23:13:32andytoshi:bramc: i think it's about timing
23:14:17andytoshi:iirc djb hinted at this but wasn't very clear in the curve25519 paper, and there isn't any other justification
23:14:23gmaxwell: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:06gmaxwell:If so it could be worked around at the expense of slowing down the code by adding more cmovs.
23:15:15gmaxwell:(and tracking an infinity flag)
23:15:21gmaxwell:Which is what we do in libsecp256k1.
23:15:51andytoshi:nsh: iirc you emailed djb about this? did you get a reply?
23:16:19gmaxwell:But if you can't you high quality standard code; it greatly reduces any advantage in one curve vs another.
23:16:52gmaxwell:since a lot of the motivation for parameters is tyed up in implementation quality.
23:16:55bramc:I mailed djb about a few things recently and haven't heard back on any of them
23:17:28ajweiss:for faster service, include qmail bug
23:18:05nsh:andytoshi, might have been more of an intention than a thing-wot-i-then-actually-done-did
23:18:19nsh:i meant to hassle him about a bunch of stuff at congress too, and he evaded me
23:18:45nsh:(by sneakily scheduling ECCHacks for when i was distracted/asleep/ondrugs/elsewhere)
23:18:55gmaxwell: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:54deego:http://www.unbreakablecoin.com/ looky! It's unbreakable! Says right there in its name. Let's switch!
23:19:56bramc: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:33bramc: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:52gmaxwell: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:14deego:(It's twice as fast, and four times the size of this puny, slow bitcoin!)
23:21:17gmaxwell:If not than regardless of what the motivations were, at a minimum that would have to change.
23:21:51bramc: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:59op_mul:deego: that's a 504.
23:22:32gmaxwell: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:43deego:op_mul: probably because the "creator" has managed to get himself slashdotted.
23:22:56deego:(did he pay dice for the advertizement?)
23:23:01sipa: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:12gmaxwell:yea, I saw that and went "hm. guess slashdot takes paid placement now."
23:23:25sipa:bramc: which means slightly faster/less code
23:23:34op_mul:deego: unbreakable is about as ominous as unsinkable.
23:23:59bramc:gmaxwell, The main motivation is it's schnorr, I guess you could use schnorr with secp256k1
23:23:59andytoshi: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:02deego:op_mul: haha
23:24:16sipa: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:20andytoshi:(in the supercop reference impl, not the optimized one)
23:24:33andytoshi:and no branching
23:24:42gmaxwell:bramc: and indeed there is an implementation in the libsecp256k1 github; though it hasn't been updated lately.
23:25:04op_mul:er. why is this "unbreakable coin" misusing bluematt's real name?
23:25:27sipa:op_mul: where?
23:26:29gmaxwell:BlueMatt: ?!
23:26:36deego:(also, wc. sorry, I thought I was talking in #bitcoin.)
23:27:01op_mul:it's a coingen coin
23:27:04gmaxwell:lol may be due to coingen!
23:27:15gmaxwell:it's a coingen altcoin? hahah
23:27:21op_mul:From: Matt Corallo
23:27:51sipa:it's not just a coingen altcoin!
23:28:01sipa:it also has a patch to chmod a leveldb script file!
23:28:12sipa:and some artwork changes
23:28:20gmaxwell:Did they add a dog?
23:29:03op_mul:I can't confirm any dog at this point in time.
23:29:24sipa:also this readme line change:
23:29:26sipa:Unbreakablecoin is based on Bitcoin's core with modifications to it's speed and size.
23:29:34sipa:(find the grammar error)
23:29:35gmaxwell:andytoshi: hurray, my memory isn't completely worthless.
23:29:45justanotheruser:sipa: their paint is thicker, rendering it unbreakable
23:29:57sipa:leaded paint
23:30:26justanotheruser:Bitcoin's core?
23:31:02bramc:Okay, really really stupid question: Schnorr works with any curve, right? Including secp256k1?
23:31:10andytoshi:gmaxwell: did you notice this as part of secp256k1 work or was it actually mentioned in the curve25519 paper?
23:32:01andytoshi: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:12sipa:bramc: yes
23:32:19sipa:well, "any" is a very large set
23:32:23sipa:but typical
23:32:37andytoshi:bramc: schnorr is group-agnostic, you only need discrete log to be hard
23:32:43sipa:bramc: there's a pull request to to add schnorr to libsecp256k1
23:33:08sipa:it's outdated now, and we probably want to do things a bit differently now
23:33:13sipa:but it would work
23:33:41gmaxwell: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:20gmaxwell: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:27op_mul:I saw some comments about making a libsecp256k low memory mode, how serious of a plan was that? :)
23:34:48bramc:sipa, It has merge conflicts now? https://github.com/bitcoin/secp256k1/pull/87
23:34:54gmaxwell:op_mul: its a few minutes hacking basically.
23:34:55sipa:bramc: as i said, it's outdated
23:35:00sipa:bramc: but the old code worked
23:35:41op_mul:gmaxwell: to get it down to < 20kB
23:36:03sipa:code size? ram size? rom size?
23:36:13sipa:including what?
23:36:34bramc:gmaxwell, It might have to do with time invariance
23:36:38gmaxwell:signing only?
23:36:42BlueMatt:op_mul: gmaxwell lol, sooooo old shit
23:36:51BlueMatt:coingen hasnt run in.....who knows how long?
23:36:52sipa:bramc: yes, it does
23:37:03sipa:bramc: it avoids a branch
23:37:07op_mul:sipa: gmaxwell: signing ideally. \
23:37:25op_mul:BlueMatt: sorry for bothing you, should have thought for a few minutes before bringing it up
23:37:35sipa:op_mul: 20 kB including what? code / static data / ram?
23:37:51BlueMatt:op_mul: lol, np
23:38:07sipa:if a 1 MB precomputed table is acceptable, it may be good already
23:38:56op_mul:sipa: limits are 120kB-ish for the flash, 20kB for the memory
23:39:43op_mul:actually, I could stop being cheap and just buy one with 2KB of flash
23:39:46bramc:Looks like ed25519 is about twice as fast http://justmoon.github.io/curvebench/benchmark.html
23:40:13gmaxwell:lol no.
23:40:19gmaxwell:Thats year old stuff.
23:40:23sipa:bramc: look at the pullreqs for that repo
23:40:29sipa:i submitted updated benchmarks
23:40:36sipa:which are outdated now too
23:40:50gmaxwell:(also it was misconfigured because it rupped out the buildsystem)
23:41:22op_mul:ah, damn, there's no 2KB flash version. limit seems to be 1KB.
23:42:01bramc:sipa, How does it do with the updated benchmark?
23:42:54sipa: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:12op_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:25sipa:with some pullreqs that are not merged yet, it's closer to 20% faster
23:43:52bramc:sipa, What's wrong with libgmp?
23:43:58sipa:more code
23:44:02kanzure:surface area
23:44:29sipa:and consensus-critical systems have much stronger requirements than typical projects
23:44:39sipa:as in: fixing a bug may not be wanted
23:44:41gmaxwell:GMP has never promised to not fix bugs.
23:45:15op_mul:gmaxwell: and it has a hardware RNG. neat.
23:45:47sipa:i trust GMP does a good job of testing and having few bugs in general, but that's not always enough
23:45:58bramc:Okay, I'm sold on the bitcoin curve
23:49:58op_mul:o.o tamper detection?
23:52:31op_mul:right. battery backed SRAM, 80 bytes.
23:53:04op_mul:enough for a BIP32 key if you felt like living dangerously.
23:55:20bramc: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?