00:25:45 | Pan0ram1x: | Pan0ram1x is now known as Guest42039 |
02:13:02 | fanquake_: | fanquake_ is now known as fanquake |
04:30:18 | justanotheruser: | justanotheruser is now known as jau87 |
04:44:49 | jau87: | jau87 is now known as justanotheruser |
06:30:52 | fanquake_: | fanquake_ is now known as fanquake |
07:52:52 | ahmed_: | ahmed_ is now known as ahmed_airport |
08:01:30 | ahmed_airport: | ahmed_airport is now known as Aforis |
08:02:23 | Aforis: | Aforis is now known as Howie |
08:03:20 | Howie: | Howie is now known as educatedwarrior_ |
08:04:56 | educatedwarrior_: | educatedwarrior_ is now known as ahmed_ |
08:05:16 | verne.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 | verne.freenode.net: | Users on #bitcoin-wizards: andy-logbot pen profreid jtimon tjopper cbeams CoinMuncher devrandom grandmaster2 p15 fanquake coinheavy waxwing moa wizkid057 mortale nuke1989 arubi tromp_ RoboTeddy ericp4 justanotheruser TheSeven BrainOverfl0w Sangheili jchp Dr-G2 Graftec artilectinc Guest42039 gribble aburan28 wumpus jrayhawk_ SDCDev jgarzik jasx zwischenzug2 tromp shesek HaltingState firepacket dgenr8 altoz irc88 tacotime arowser wiretapped Starduster jaekwon1 go1111111 |
08:05:16 | verne.freenode.net: | Users on #bitcoin-wizards: zenojis LarsLarsen spinza BigBitz EasyAt samson_ emsid Adohgg Hunger- mkarrer drawingthesun Kretchfoop berndj [d__d] jcorgan copumpkin c0rw1n lysobit yoleaux Transisto Iriez hollandais ebfull Aquent lnovy hguux livegnik rfreeman_w stonecoldpat Dyaheon Fistful_of_coins digitalmagus MRL-Relay artifexd _2539 mappum jbenet [Derek] zibbo_ kanzure Luke-Jr petertodd optimator [\\\] Grishnakh warren pi07r K1773R Eliel HM gmaxwell amiller_ crescendo |
08:05:17 | verne.freenode.net: | Users on #bitcoin-wizards: cfields btc_ kgk bobke iddo comboy Happzz NikolaiToryzin coryfields michagogo LaptopZZ Meeh poggy_ Emcy_ UukGoblin phedny @ChanServ burcin lechuga_ abc56889 Alanius throughnothing harrow DoctorBTC phantomcircuit [nsh] sipa asoltys Taek42 Krellan Nightwolf Anduck forrestv SomeoneWeird bbrittain fluffypony mr_burdell Apocalyptic lianj pigeons kinlo Graet midnightmagic starsoccer a5m0 BlueMatt epscy so andytoshi espes__ nanotube Logicwax Muis |
08:05:17 | verne.freenode.net: | Users on #bitcoin-wizards: ahmed_ Gnosis Keefe sl01 pajarillo roasbeef mmozeiko ryan-c gwillen otoburb smooth helo [Tristan] TD-Linux catcow danneu |
08:05:17 | verne.freenode.net: | [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup |
09:32:33 | Eliel: | if only there was a sensible way to reward people for validating. I haven't seen any Proof of Validation schemes yet :P |
09:34:26 | moa: | people validate because they have an economic incentive to check (self-)ownership |
10:11:48 | spinza: | Like the cost of holding cash. It's the cost of the security? Makes sense. |
11:55:23 | Guyver2: | Guyver2 has left #bitcoin-wizards |
12:49:53 | fanquake_: | fanquake_ is now known as fanquake |
14:45:42 | cbeams_: | cbeams_ is now known as cbeams |
15:35:36 | andytoshi: | gmaxwell: i think to make the security definition sensible for the boneh-style n-of-m schnorr you need to move the interaction into the sign phase.. |
15:36:11 | andytoshi: | gmaxwell: consider 2-of-3 with parties A, B, C. A&B run setup to obtain C's key; B&C run setup to obtain A's key; now B has all three keys and can sign whatever he likes |
15:36:51 | andytoshi: | whereas for a "one-time signature" e.g. lamport the security def is that only one thing gets signed ... so if the interaction happens in the sign phase we are within bounds of this definition. otherwise we need our own adhoc definition |
16:04:52 | gmaxwell: | andytoshi: You've missed something, in the two of three case you do not end up with any party that knows all the keys. |
16:05:54 | andytoshi: | gmaxwell: i'm saying if A&B do the setup -and- B&C do the setup, so B is screwing around |
16:07:17 | gmaxwell: | You end up with C knowing, say, A's key and B+r where r is a random blinding factor. A also knows r, so they can sign with A-r + B+r. If only one of the players screws around, and does the setup again, he'll get completely unrelated keys, since you can't reuse keys or random factors during setup/. |
16:09:30 | andytoshi: | oh, i see, i was doing waay too much in the keygen phase |
16:18:34 | andytoshi: | after A&B do the setup, B knows the keys for B and C right? |
16:22:20 | andytoshi: | oh, derp, i'm being stupid, i did have the right scheme, i'm just reading it wrong |
16:53:48 | gmaxwell: | There is no 'C key' in that scheme. |
17:01:42 | andytoshi: | right, i got it. i was doing something stupid to make my life easier generalizing to arbitrary monotone fns |
17:02:15 | andytoshi: | ("something stupid" being, having all parties actually generate the keys for the absent ones :P) |
19:14:42 | [nsh]: | monotone? monotonic, as in without inflexion? |
19:14:46 | [nsh]: | (andytoshi) |
19:19:44 | andytoshi: | [nsh]: a monotone function is one for which any superset of a satisfying input is also a satisfying input |
19:19:51 | andytoshi: | (it is a function from a bunch of bits to a single bit) |
19:20:12 | andytoshi: | [nsh]: http://research.microsoft.com/apps/pubs/default.aspx?id=68345 |
19:20:55 | andytoshi: | another term for monotone function is "a circuit made from AND, OR and threshold gates" (this equivalence is the main result of that paper imho, tho they sorta meander and don't draw attention to it) |
19:22:11 | [nsh]: | ah, ty |
20:01:37 | austinhill: | |
20:28:25 | Taek42: | when calculating the difficulty of a Bitcoin chain, do I sum the target difficulty of each block, or the maximum difficulty that the block could satisfy? |
20:30:38 | gmaxwell: | Taek42: You should think about what the differences are and implications, and you'll likely learn something useful! |
20:32:00 | Taek42: | alright, thinking out loud. If you used the maximum possible difficulty, it would be possible to wipe the entire history of many blocks with a single block |
20:34:14 | Taek42: | at the same time, there doesn't seem to be a point to trying to find a block of higher difficulty at a point you want to reorganize, it seems like it would be better to just keep releasing blocks as you find them |
20:34:21 | Taek42: | as it would reduce the variance |
20:35:48 | Taek42: | hmm. If you find 2 blocks of difficulty N, it's roughly as difficult as finding 1 block of difficulty 2N. |
20:36:18 | Taek42: | If you were to count total possible difficulty of two blocks at difficulty 2N, you'd get a score like 3N |
20:36:30 | Taek42: | but it would only represent 2N hashes |
20:36:59 | Taek42: | if you count only target difficulty, you have 2N hashes that gets a score of 2N |
20:38:23 | helo: | if blocks came out on average every 10 minutes as expected, the difficulty shouldn't change (duh myself) |
20:39:03 | helo: | if you summed up the "seeming" difficulty, the chain would appear to be more difficult than the difficulty is set at |
20:39:26 | Taek42: | The overflow gives you free apparent difficulty, but doesn't that overflow apply to everyone? Aren't honest miners going to have the same amount of overflow as difficult miners? |
20:39:32 | Taek42: | *dishonest miners |
20:41:04 | helo: | yeah, the distribution will be the same unless there is a dishonest miner that is for some reason only publishing their "really low" blocks |
20:42:12 | helo: | if the target difficulty is used, then that kind of behavior doesn't make a bit of difference (aside from depriving themselves of the block reward) |
20:44:55 | Taek42: | if the dishonest miners are only publishing really low blocks, how does that help them? To get a low block to publish, you have to be mining on the main chain |
20:45:21 | Taek42: | I guess finding a high block means they have a head start on causing a fork |
20:45:47 | Taek42: | if they wait until they have a 1/16th likely high block, chances are low that the next few blocks will pass the value of their single high block |
20:46:08 | Taek42: | and so they can keep it to themselves and cause a bunch of stale mining. |
20:46:20 | Taek42: | so I guess that solves the mystery. |
20:47:56 | helo: | right, it could make history rewriting easier |
20:50:37 | Taek42: | I don't think it would make rewriting easier except in the case where you are rewriting from where the main chain currently is. It would make a 50% attack easier though if you could use the technique to cause more stale mining. |
21:04:55 | andytoshi: | gmaxwell: i think this is correct: https://bitcointalk.org/index.php?topic=814935.msg9117075#msg9117075 |
21:14:24 | gmaxwell: | andytoshi: I believe iwilcox's page specifically covers that case. |
21:26:12 | andytoshi: | ah, i found it, i'll respond |
21:42:51 | grandmaster2: | grandmaster2 is now known as dansmith_btc |
23:05:31 | gmaxwell: | petertodd: do you have someplace a good post (e.g. on bitcoin talk) talking over various security options for off-chain transactions? |
23:06:15 | gmaxwell: | ah okay, found the post I was thinking of. |
23:06:25 | gmaxwell: | https://bitcointalk.org/index.php?topic=146307.0 |
23:21:24 | [nsh]: | bitcointalk down for me |
23:21:39 | Taek42: | up here |
23:22:08 | kanzure: | http://web.archive.org/web/*/https://bitcointalk.org/index.php?topic=146307.0 |
23:24:59 | moa: | gmaxwell: petertodd : was there any progress on 'Trustbits' or any similar chaum-blinded, nLockTime, fidelity-bonded off-chain TX solution? |
23:25:42 | moa: | be interested to see that ... even if it is just scraps of random code or etc on github or somewhere? |
23:34:14 | [nsh]: | (turns out bitcointalk.org had ended up in my hostsfile as a place to avoid. take from that what you will...) |