02:14:06 | Boolos: | Boolos has left #bitcoin-wizards |
02:24:02 | jaekwon: | A question on Schnorr signatures... |
02:24:05 | jaekwon: | 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:12 | jaekwon: | Why must c depend on r? Say, why can't c just be h(m)? |
02:30:42 | tromp: | message m might be involved in multiple signatures |
02:33:21 | jaekwon: | tromp: Hmm.. interesting. Fortunately I know that m won't be involved in multiple signatures. |
02:43:39 | andytoshi: | jaekwon: an academic reason for c to be a fn of r is that you can't prove it secure otherwise.. |
02:44:28 | andytoshi: | 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:42 | jaekwon: | 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:32 | andytoshi: | 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:40 | andytoshi: | existential unforgeability* |
02:48:06 | Pasha: | Pasha is now known as Cory |
02:49:06 | jaekwon: | hmm… (moving the conversation to ##crypto since you're there too) |
02:49:32 | andytoshi: | kk |
08:05:16 | morgan.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 |
08:05:16 | morgan.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:16 | morgan.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:16 | morgan.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:16 | morgan.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:54 | jaekwon: | || 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:30 | jaekwon: | 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:27 | jaekwon: | How much should a coin miner/validator be punished for delaying all transactions for 1 second? |
10:07:20 | jaekwon: | That's the minimum surety bond. |
10:46:30 | Eliel: | 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:47 | Eliel: | that will then naturally also be the loss incurred if they start delaying |
12:25:22 | andytoshi: | 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:58 | andytoshi: | 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:09 | samson2: | samson2 is now known as samson_ |
12:46:33 | fanquake: | fanquake has left #bitcoin-wizards |
14:07:07 | x48_: | x48_ is now known as x48 |
14:25:43 | Guest2024: | Guest2024 is now known as artifexd |
15:53:45 | jedunnigan: | jedunnigan is now known as Guest68080 |
17:12:39 | nuke_: | nuke_ is now known as nuke1989 |
18:08:38 | asoltys: | /whois |
19:05:16 | jedunnigan: | jedunnigan is now known as Guest27591 |
19:11:13 | helo: | helo is now known as james_russel |
19:11:27 | james_russel: | james_russel is now known as helo |
19:33:36 | Aquent: | Aquent is now known as ppvkignx |
19:33:53 | ppvkignx: | ppvkignx is now known as Aquent |
19:43:25 | gwillen: | gwillen is now known as edwardpryan |
19:43:59 | edwardpryan: | edwardpryan is now known as gwillen |
20:21:59 | bsm117532: | 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:53 | Quanttek_: | Quanttek_ is now known as Quanttek |
20:27:19 | helo: | bsm117532: i suspect multiple nonces does not present any more information about a miner's mining power |
20:29:09 | bsm117532: | 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:50 | bsm117532: | 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:22 | bsm117532: | How to use this information is an exercise left to the reader... |
20:31:26 | helo: | 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:46 | Eliel: | helo: it'd mean that too in practise I think |
20:32:14 | bsm117532: | Why would it widen the nonce space? |
20:32:29 | Eliel: | bsm117532: the nonce is currently only 32 bits. |
20:33:06 | Eliel: | you have to twiddle with the merkle tree or transactions (mainly coinbase) to get more variability |
20:33:11 | bsm117532: | Surely miners are running through more than 4 billion... |
20:33:56 | bsm117532: | 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:30 | helo: | "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:31 | bsm117532: | Just add an OP_RETURN transaction to contain extranonce...or something. |
20:34:52 | bsm117532: | helo: What do you mean "progress free"? |
20:35:55 | helo: | bsm117532: every attempt is completely disctinct and has an equal chance of being a solution |
20:36:28 | Eliel: | I think it's explained in detail here https://download.wpsoftware.net/bitcoin/asic-faq.pdf |
20:36:29 | bsm117532: | That could still be true. |
20:36:30 | helo: | oh, so a miner would still submit as soon as they come up with a single nonce that solves the block |
20:36:50 | helo: | it's just that they'd also submit the N next best nonces |
20:37:01 | bsm117532: | yes. Or something of that nature. |
20:37:46 | helo: | i think (assuming everyone was honest) all blocks would look the same regardless of the power of the miner that found them |
20:38:12 | helo: | i.e. the same number of hashes on average are required to find a solution at a particular difficulty |
20:38:31 | nsh: | 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:39 | nsh: | *prior to |
20:38:54 | helo: | 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:09 | Eliel: | bsm117532: what were you thinking to use the data for from the not good enough for a block attempts? |
20:39:30 | bsm117532: | A better difficulty target algorithm. |
20:39:37 | nsh: | oui, monsieur poisson |
20:39:40 | helo: | yeah, it's not better :/ |
20:40:00 | bsm117532: | nsh: leave my fish alone!!! |
20:40:04 | nsh: | * nsh smiles |
20:40:06 | Eliel: | bsm117532: I don't see a need for a better algorithm. Wht are you trying to fix? |
20:40:26 | nsh: | it gets less better as a function of how much success depends on more than one atomic calculation |
20:40:36 | bsm117532: | 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:39 | nsh: | the luddites were right: progress is bad, |
20:41:49 | Eliel: | bsm117532: there's enough variability in the electricity prices that it's unlikely to be a real problem. |
20:42:03 | bsm117532: | One hopes, one hopes. |
20:42:08 | bsm117532: | I like math better than hopes. |
20:43:37 | nsh: | if hopes were walruses, then beggars would.. have a lot of walruses |
20:44:55 | Eliel: | there are good reasons to keep difficulty from reacting fast.. |
20:45:29 | bsm117532: | Eliel: why? I have not seen any good analysis on this. |
20:45:57 | nsh: | too aggressive retargeting can be gamed or simply fall into oscillations |
20:46:56 | bsm117532: | Oscillations can be damped, and any system can be gamed. Again, it needs analysis that I've not seen anyone do... |
20:47:53 | Eliel: | well, there are practical examples in the altcoin space |
20:47:53 | bsm117532: | And actually I don't see oscillations as any kind of a problem. Gaming is a worse problem. |
20:48:22 | bsm117532: | Eliel: naive examples, yes. I can do better than KGW with my eyes closed. |
20:50:10 | nsh: | andytoshi was going to address this in the alts faq, not sure if he has had a chance yet |
20:50:19 | nsh: | (ref. http://download.wpsoftware.net/bitcoin/wizards/2014-05-06.html) |
20:51:16 | bsm117532: | I've read his alts faq. |
20:51:31 | helo: | 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:46 | helo: | that's the "naive" example? |
20:52:46 | bsm117532: | It's an example of what I'm worried about, yes. |
20:54:26 | bsm117532: | 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:13 | bsm117532: | But turning it on for only an hour to generate a fork could be very profitable, in the wrong hands. |
21:05:22 | helo: | there were similar fears voiced when the reward halved |
21:11:01 | bsm117532: | It may not have happened yet (difficulty is still rising) but someday the difficulty will stop growing. |
21:11:30 | bsm117532: | I think the security of bitcoin is dependent on monotonically increasing difficulty. It's dangerous. |
21:22:30 | ericp4: | ericp4 has left #bitcoin-wizards |
21:24:19 | andytoshi: | bsm117532: it does not |
21:24:31 | helo: | the existence of dark miners is always a possibility |
21:24:45 | woah: | what if the price keeps increasing? will humanity end up using 100% of electrical output to mine? |
21:24:49 | andytoshi: | 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:30 | bsm117532: | 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:53 | bsm117532: | BTW what's the official source for alts.pdf? I have http://download.wpsoftware.net/bitcoin/alts.pdf |
21:26:04 | bsm117532: | The bitcoin wiki has a very old version from January too... |
21:26:25 | andytoshi: | bsm117532: based on the abstract, that paper is gibberish |
21:26:41 | bsm117532: | andytoshi: agreed. It does have a lot of interesting discussion of mining, however. |
21:26:52 | bsm117532: | If I read between the lines, I think this guy got screwed investing in mining companies. |
21:26:59 | bsm117532: | And has his panties in a wad. |
21:27:00 | andytoshi: | 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:23 | nsh: | wikis are communist anyway |
21:27:34 | andytoshi: | 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:46 | andytoshi: | tim swanson's "bitcoins: made in china" has some good graphs and projections about mining distribution |
21:27:52 | andytoshi: | nsh: lol |
21:28:15 | bsm117532: | cool thanks (re bitcoins: made in china) |
21:28:35 | nsh: | obsoleted hardware isn't generally turned to nefarious use when its legitimate utility becomes negative, historically-speaking |
21:28:40 | nsh: | except in rare cases |
21:28:54 | nsh: | the incentives might be slightly more explicit in the case of mining, but most people really can't be bothered |
21:28:55 | andytoshi: | 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:03 | bsm117532: | nsh: hey all the hash rate dumped onto alt coins came from somewhere... ;-) |
21:29:13 | nsh: | the investment will just be written off and you have some shiny paperweights |
21:29:21 | andytoshi: | 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:23 | Eliel: | woah: no, markets don't quite work that way. |
21:29:30 | nsh: | some would argue ruining altcoins isn't necessarily nefarious... ;) |
21:30:07 | andytoshi: | oh wait, i did read it :} he credited me for reviewing |
21:31:01 | bsm117532: | hahaa ;-) |
21:31:20 | woah: | here's an interesting one- is bitcoin any more secure than it was 4 years ago? |
21:31:37 | nsh: | against which threats? |
21:31:45 | woah: | double-spend |
21:31:48 | bsm117532: | woah: I could argue that both ways. I'm bi-securital. |
21:32:18 | nsh: | numerically, yes. collective-behaviourally, hard to say |
21:32:40 | nsh: | (where collective behaviour includes letting random anonymous people control your hash power) |
21:32:55 | Eliel: | woah: absolutely speaking, more secure. relatively speaking, perhaps a little less secure. (cryptic enough yet? :D) |
21:33:30 | woah: | hm |
21:33:49 | nsh: | Ned: But Reverend, I need to know, is God punishing me? |
21:33:49 | nsh: | 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:00 | woah: | will mining power consumption increase in proportion to currency price? |
21:35:05 | Eliel: | woah: Until the block reward halves again, yes. |
21:35:26 | bsm117532: | woah: absolutely, yes. |
21:35:41 | woah: | will it ever stop? |
21:36:03 | bsm117532: | 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:53 | bsm117532: | Miners are "paying" for BTC with their investments, and are not going to make those investments unless they make financial sense. |
21:37:03 | Eliel: | woah: mining power consumption will always tend towards using as much electricity as the block rewards are worth. |
21:37:22 | Eliel: | and the block rewards halve every 4 years. |
21:37:24 | woah: | so the rise in consumption is naturally moderated by halving |
21:37:51 | Eliel: | well, at some point transaction fees will be more important than the reward. |
21:38:08 | Eliel: | but I have no idea when that will be. |
21:38:17 | bsm117532: | I think transaction fees are already about half of the block reward. |
21:38:49 | Eliel: | bsm117532: huh? was not even close the last time I looked. |
21:38:56 | bsm117532: | * bsm117532 looks for that plot... |
21:39:41 | bsm117532: | https://blockchain.info/charts/transaction-fees |
21:39:46 | bsm117532: | about 10-12 BTC it seems |
21:40:02 | Eliel: | yes, per day |
21:40:13 | bsm117532: | ooooohhhhh oops. |
21:40:15 | Eliel: | block rewards are 6*24*25BTC |
21:40:29 | bsm117532: | Well that's a goddamn useless umber. |
21:40:31 | bsm117532: | *number |
21:41:11 | bsm117532: | Nowhere on there does it say "per day". |
21:42:08 | Eliel: | well, mine is an educated guess that's based on the fact that most graphs in there are per day graphs |
21:42:43 | bsm117532: | You're right, looking at the raw data. It's per day. |
21:43:17 | bsm117532: | So it's about 70 mBTC per block. |
21:44:49 | Eliel: | at least the fees are enough already that they'd pay for a lunch per block found ;) |
22:42:08 | andytoshi: | 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:30 | jaekwon: | andytoshi: that poncho guy… he's good. :) |
22:44:48 | andytoshi: | 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:38 | fluffypony: | of course |
23:10:16 | x48_: | x48_ is now known as x48 |