02:14:06Boolos:Boolos has left #bitcoin-wizards
02:24:02jaekwon:A question on Schnorr signatures...
02:24:05jaekwon:Say y = g^x, r = g^v, c = h(m||r), z = v+cx mod q, and (r, z) is the signature.  Then you can verify with g^z = ry^c mod p.
02:24:12jaekwon:Why must c depend on r?  Say, why can't c just be h(m)?
02:30:42tromp:message m might be involved in multiple signatures
02:33:21jaekwon:tromp: Hmm.. interesting. Fortunately I know that m won't be involved in multiple signatures.
02:43:39andytoshi:jaekwon: an academic reason for c to be a fn of r is that you can't prove it secure otherwise..
02:44:28andytoshi:jaekwon: only plausible security proof of schnorr is in the random oracle model, and if you can't reprogram the RO for each query you can't construct a usable sim (tho you can if you restrict to one message == one sig)
02:46:42jaekwon:andytoshi: hmm… so if c were h(m), given a valid signature anyone could generate multiple valid signatures for the same message. And this isn't compatible with known security proofs using the RO model?
02:47:32andytoshi:jaekwon: that's right, standard security property for sigs is "essential unforgeability" but this doesn't apply to messages the attacker has already seen (what we have been calling "malleability")
02:47:40andytoshi:existential unforgeability*
02:48:06Pasha:Pasha is now known as Cory
02:49:06jaekwon:hmm… (moving the conversation to ##crypto since you're there too)
08:05:16morgan.freenode.net:Users on #bitcoin-wizards: andy-logbot ebfull samson_ digitalmagus8 vfor fanquake HaltingState chris2000 damethos todaystomorrow koshii marshallswatt nullbyte dgenr8 coinheavy pen TheSeven zooko eslbaer_ irc88 p15 napedia roconnor prepost vmatekol_ atgreen wizkid057 justanotheruser Aquent Emcy spinza mappum SDCDev Grishnakh grandmaster2 br4n altoz nuke1989 skinnkavaj Adlai wiretapped iddo bsm117532 OneFixt mortale drawingthesun quackgyver starsoccer midnightmagic Adohgg
08:05:16morgan.freenode.net:Users on #bitcoin-wizards: jaekwon Muis Starduster_ berndj-blackout arowser1 LarsLarsen toysrough gribble Graftec nsh Graet melvster devrandom kinlo jgarzik Transisto zenojis hollandais nanotube [Derek] BlueMatt Dyaheon CryptOprah_ jbenet promoJo michagogo zlinn_ btc_ Guest2024 copumpkin ericp4 pigeons BrainOverfl0w lianj_ UukGoblin optimator wumpus Apocalyptic poggy rs0 jcorgan_ Iriez mr_burdell fluffypony epscy K1773R a5m0 go1111111 bbrittain SomeoneWeird mikalv
08:05:16morgan.freenode.net:Users on #bitcoin-wizards: forrestv shesek livegnik mkarrer Anduck amiller Nightwolf Keefe Krellan BigBitz [\\\] dansmith_btc Taek42 jaromil warren asoltys Hunger- waxwing @ChanServ phedny so petertodd burcin LaptopZZ danneu catcow TD-Linux lechuga_ abc56889 weex Guest50253 helo smooth otoburb gwillen kanzure ryan-c pi07r nickler_ Alanius Guest47516 throughnothing CodeShark Eliel mmozeiko andytoshi roasbeef harrow DoctorBTC Fistful_of_coins gmaxwell zibbo phantomcircuit
08:05:16morgan.freenode.net:Users on #bitcoin-wizards: maaku HM crescendo pajarillo nsh- bobke [d__d] coryfields sipa espes__ Luke-Jr comboy_ sl01 tromp Logicwax tucenaber EasyAt tromp_
09:58:54jaekwon:|| Q: Is there an efficient way to batch-verify signatures (e.g. some may be incorrect) and then non-interactively aggregate the correct ones into a multisignature (they are of the same message) such that all operations are fast (e.g. don't require linear pairing operations)?
10:02:30jaekwon:andytoshi: I think that up there ^ is the best way to describe my problem. I think I can punt on the problem though, via a scheme that involves binary searching on a list of signature pairs.
10:06:27jaekwon:How much should a coin miner/validator be punished for delaying all transactions for 1 second?
10:07:20jaekwon:That's the minimum surety bond.
10:46:30Eliel:jaekwon: wouldn't be easier to reason about how big of a carrot is needed to get a miner/validator to improve their speed?
10:49:47Eliel:that will then naturally also be the loss incurred if they start delaying
12:25:22andytoshi:jaekwon: you want an aggregatable signature, then if the whole thing was invalid, you'd aggregate each half and check which one(s) were bad, and so on, and bisect down to the bad ones
12:25:58andytoshi:i expect you'll have an easier time finding an aggregatable sig with sublinear scaling than one that directly solves your "find all the good ones" problem
12:42:09samson2:samson2 is now known as samson_
12:46:33fanquake:fanquake has left #bitcoin-wizards
14:07:07x48_:x48_ is now known as x48
14:25:43Guest2024:Guest2024 is now known as artifexd
15:53:45jedunnigan:jedunnigan is now known as Guest68080
17:12:39nuke_:nuke_ is now known as nuke1989
19:05:16jedunnigan:jedunnigan is now known as Guest27591
19:11:13helo:helo is now known as james_russel
19:11:27james_russel:james_russel is now known as helo
19:33:36Aquent:Aquent is now known as ppvkignx
19:33:53ppvkignx:ppvkignx is now known as Aquent
19:43:25gwillen:gwillen is now known as edwardpryan
19:43:59edwardpryan:edwardpryan is now known as gwillen
20:21:59bsm117532:So here's another funny idea: what if instead of a single nonce representing the PoW, what if there were several? Thereby, the miner would be representing more statistical information about his mining power. If you had that, one could use the actual work (represented by the average of several hashes) instead of targetted.
20:26:53Quanttek_:Quanttek_ is now known as Quanttek
20:27:19helo:bsm117532: i suspect multiple nonces does not present any more information about a miner's mining power
20:29:09bsm117532:It does: presenting one nonce presents the minimum hash value over some time interval. By presenting several, one is less likely to "get lucky" and generate a very small hash.
20:30:50bsm117532:Imagining the hash as a binary value on [0.0, 1.0] one could choose several points 0.0, 0.1, 0.2, ... and present the 10 hashes closest to those values that you've discovered. This gives a measure of the miner's overall hash rate, even if the one closest to 0.0 is anomalously low.
20:31:22bsm117532:How to use this information is an exercise left to the reader...
20:31:26helo:oh, you mean a block would include multiple nonces that each represent a solution. i thought what you were saying was analogous to widening the nonce space.
20:31:46Eliel:helo: it'd mean that too in practise I think
20:32:14bsm117532:Why would it widen the nonce space?
20:32:29Eliel:bsm117532: the nonce is currently only 32 bits.
20:33:06Eliel:you have to twiddle with the merkle tree or transactions (mainly coinbase) to get more variability
20:33:11bsm117532:Surely miners are running through more than 4 billion...
20:33:56bsm117532:Well, for the sake of argument, let's say the nonce was 64 bits, or 256 bits. I'm interested in what one could do with this statistical information more than how to technically implement it.
20:34:30helo:"progress free" is an important facet of the PoW, and requiring multiple solutions (if i understand what you're suggesting) would break that
20:34:31bsm117532:Just add an OP_RETURN transaction to contain extranonce...or something.
20:34:52bsm117532:helo: What do you mean "progress free"?
20:35:55helo:bsm117532: every attempt is completely disctinct and has an equal chance of being a solution
20:36:28Eliel:I think it's explained in detail here https://download.wpsoftware.net/bitcoin/asic-faq.pdf
20:36:29bsm117532:That could still be true.
20:36:30helo:oh, so a miner would still submit as soon as they come up with a single nonce that solves the block
20:36:50helo:it's just that they'd also submit the N next best nonces
20:37:01bsm117532:yes. Or something of that nature.
20:37:46helo:i think (assuming everyone was honest) all blocks would look the same regardless of the power of the miner that found them
20:38:12helo:i.e. the same number of hashes on average are required to find a solution at a particular difficulty
20:38:31nsh:a miner doesn't find a block -- a double round of sha256 does. what happened previously to that round is irrelevant in principle
20:38:39nsh:*prior to
20:38:54helo:it's just as unlikely for a miner with a tiny hashrate to find a block after only a few hashes as it would be for a miner with a large hashrate
20:39:09Eliel:bsm117532: what were you thinking to use the data for from the not good enough for a block attempts?
20:39:30bsm117532:A better difficulty target algorithm.
20:39:37nsh:oui, monsieur poisson
20:39:40helo:yeah, it's not better :/
20:40:00bsm117532:nsh: leave my fish alone!!!
20:40:04nsh:* nsh smiles
20:40:06Eliel:bsm117532: I don't see a need for a better algorithm. Wht are you trying to fix?
20:40:26nsh:it gets less better as a function of how much success depends on more than one atomic calculation
20:40:36bsm117532:Rapid changes in hashrate, for when BTC price drops low enough that miners are incentivized to turn off their equipment, and could dump it back on for a 51% attack.
20:40:39nsh:the luddites were right: progress is bad,
20:41:49Eliel:bsm117532: there's enough variability in the electricity prices that it's unlikely to be a real problem.
20:42:03bsm117532:One hopes, one hopes.
20:42:08bsm117532:I like math better than hopes.
20:43:37nsh:if hopes were walruses, then beggars would.. have a lot of walruses
20:44:55Eliel:there are good reasons to keep difficulty from reacting fast..
20:45:29bsm117532:Eliel: why? I have not seen any good analysis on this.
20:45:57nsh:too aggressive retargeting can be gamed or simply fall into oscillations
20:46:56bsm117532:Oscillations can be damped, and any system can be gamed. Again, it needs analysis that I've not seen anyone do...
20:47:53Eliel:well, there are practical examples in the altcoin space
20:47:53bsm117532:And actually I don't see oscillations as any kind of a problem. Gaming is a worse problem.
20:48:22bsm117532:Eliel: naive examples, yes. I can do better than KGW with my eyes closed.
20:50:10nsh:andytoshi was going to address this in the alts faq, not sure if he has had a chance yet
20:50:19nsh:(ref. http://download.wpsoftware.net/bitcoin/wizards/2014-05-06.html)
20:51:16bsm117532:I've read his alts faq.
20:51:31helo:nothing more complicated than - bill gates pumps $2B worth of electricity into mining for two weeks to skyrocket the difficulty 100x, and then pulls the plug, it would take 1000 minutes for the miners to find blocks until the next retarget
20:51:46helo:that's the "naive" example?
20:52:46bsm117532:It's an example of what I'm worried about, yes.
20:54:26bsm117532:More practically, as time goes on, if BTC falls in price, there will exist unused mining hardware looking for a use, that cannot be cost-effectively used based on the coinbase reward.
20:55:13bsm117532:But turning it on for only an hour to generate a fork could be very profitable, in the wrong hands.
21:05:22helo:there were similar fears voiced when the reward halved
21:11:01bsm117532:It may not have happened yet (difficulty is still rising) but someday the difficulty will stop growing.
21:11:30bsm117532:I think the security of bitcoin is dependent on monotonically increasing difficulty. It's dangerous.
21:22:30ericp4:ericp4 has left #bitcoin-wizards
21:24:19andytoshi:bsm117532: it does not
21:24:31helo:the existence of dark miners is always a possibility
21:24:45woah:what if the price keeps increasing? will humanity end up using 100% of electrical output to mine?
21:24:49andytoshi:i have addressed diffchanges in alts.pdf, but didn't say anything interesting (roughly, don't introduce gaming, and don't do anything else because it's basically pointless)
21:25:30bsm117532:Yeah I just ran into http://arxiv.org/pdf/1405.0534v8.pdf but was going to check your alts.pdf for comments on this next.
21:25:53bsm117532:BTW what's the official source for alts.pdf? I have http://download.wpsoftware.net/bitcoin/alts.pdf
21:26:04bsm117532:The bitcoin wiki has a very old version from January too...
21:26:25andytoshi:bsm117532: based on the abstract, that paper is gibberish
21:26:41bsm117532:andytoshi: agreed. It does have a lot of interesting discussion of mining, however.
21:26:52bsm117532:If I read between the lines, I think this guy got screwed investing in mining companies.
21:26:59bsm117532:And has his panties in a wad.
21:27:00andytoshi:bsm117532: the "official source" is the link you posted. i've been asked many times to mirror it on the wiki, but it's a huge PITA so i won't while it's a work in progress
21:27:23nsh:wikis are communist anyway
21:27:34andytoshi:well, i'm not sure how interesting he can be about mining when he appears to have no clue what mining is for..
21:27:46andytoshi:tim swanson's "bitcoins: made in china" has some good graphs and projections about mining distribution
21:27:52andytoshi:nsh: lol
21:28:15bsm117532:cool thanks (re bitcoins: made in china)
21:28:35nsh:obsoleted hardware isn't generally turned to nefarious use when its legitimate utility becomes negative, historically-speaking
21:28:40nsh:except in rare cases
21:28:54nsh:the incentives might be slightly more explicit in the case of mining, but most people really can't be bothered
21:28:55andytoshi:http://www.ofnumbers.com/wp-content/uploads/2014/05/Bitcoins-Made-in-China.pdf is the url i have for tim swanson's article
21:29:03bsm117532:nsh: hey all the hash rate dumped onto alt coins came from somewhere... ;-)
21:29:13nsh:the investment will just be written off and you have some shiny paperweights
21:29:21andytoshi:full disclosure i've never actually read it, but i talked to him for several weeks about asic-faq.pdf and i did read a distilled HTML version
21:29:23Eliel:woah: no, markets don't quite work that way.
21:29:30nsh:some would argue ruining altcoins isn't necessarily nefarious... ;)
21:30:07andytoshi:oh wait, i did read it :} he credited me for reviewing
21:31:01bsm117532:hahaa ;-)
21:31:20woah:here's an interesting one- is bitcoin any more secure than it was 4 years ago?
21:31:37nsh:against which threats?
21:31:48bsm117532:woah: I could argue that both ways. I'm bi-securital.
21:32:18nsh:numerically, yes. collective-behaviourally, hard to say
21:32:40nsh:(where collective behaviour includes letting random anonymous people control your hash power)
21:32:55Eliel:woah: absolutely speaking, more secure. relatively speaking, perhaps a little less secure. (cryptic enough yet? :D)
21:33:49nsh:Ned: But Reverend, I need to know, is God punishing me?
21:33:49nsh:Lovejoy: Shooh, short answer: "Yes" with an "If," long answer: "No" -- with a "But." Uh, if you need additional solace, by the way, I've got a copy of something or other by Art Linkletter in my office.
21:34:00woah:will mining power consumption increase in proportion to currency price?
21:35:05Eliel:woah: Until the block reward halves again, yes.
21:35:26bsm117532:woah: absolutely, yes.
21:35:41woah:will it ever stop?
21:36:03bsm117532:If you divide out the cost of electricity and assuming no change in technology, difficulty and BTC price would match each other (up to shocks due to news, etc).
21:36:53bsm117532:Miners are "paying" for BTC with their investments, and are not going to make those investments unless they make financial sense.
21:37:03Eliel:woah: mining power consumption will always tend towards using as much electricity as the block rewards are worth.
21:37:22Eliel:and the block rewards halve every 4 years.
21:37:24woah:so the rise in consumption is naturally moderated by halving
21:37:51Eliel:well, at some point transaction fees will be more important than the reward.
21:38:08Eliel:but I have no idea when that will be.
21:38:17bsm117532:I think transaction fees are already about half of the block reward.
21:38:49Eliel:bsm117532: huh? was not even close the last time I looked.
21:38:56bsm117532:* bsm117532 looks for that plot...
21:39:46bsm117532:about 10-12 BTC it seems
21:40:02Eliel:yes, per day
21:40:13bsm117532:ooooohhhhh oops.
21:40:15Eliel:block rewards are 6*24*25BTC
21:40:29bsm117532:Well that's a goddamn useless umber.
21:41:11bsm117532:Nowhere on there does it say "per day".
21:42:08Eliel:well, mine is an educated guess that's based on the fact that most graphs in there are per day graphs
21:42:43bsm117532:You're right, looking at the raw data. It's per day.
21:43:17bsm117532:So it's about 70 mBTC per block.
21:44:49Eliel:at least the fees are enough already that they'd pay for a lunch per block found ;)
22:42:08andytoshi:jaekwon: just read https://crypto.stackexchange.com/questions/19292/is-this-modified-schnorr-signature-scheme-secure .... oops!! i should've caught that, sorry
22:44:30jaekwon:andytoshi: that poncho guy… he's good. :)
22:44:48andytoshi:i was being lazy, thought, "oh, just program H(m) same as you would H(m||g^k) in the ordinary schnorr scheme, then you have the same security proof" but ofc in the latter the adversary has to commit to k before querying the oracle, in this one he dosn't
22:45:38fluffypony:of course
23:10:16x48_:x48_ is now known as x48