00:00:53 | midnightmagic: | gmaxwell: http://magicrulesunpaa6.onion/rich_people_and_ethics_bib.txt I don't think it's an availability bias or a researcher shelving bias, as a badly-written review of Piff's work asserted. |
00:02:21 | justanotheruser: | justanotheruser is now known as just[dead] |
00:13:41 | just[dead]: | just[dead] is now known as justanotheruser |
00:33:01 | justanotheruser: | justanotheruser is now known as just[dead] |
01:28:46 | HobGoblin: | HobGoblin is now known as Guest27571 |
01:50:55 | roasbeef_: | roasbeef_ is now known as roasbeef |
02:16:35 | BCB: | BCB has left #bitcoin-wizards |
03:08:54 | Emcy_: | http://torrentfreak.com/bitcoin-donations-now-integrated-into-bittorrent-client-140227/ seems cool |
03:09:58 | Emcy_: | it seems like it just opens bitpay or something |
03:10:14 | Emcy_: | would have been nicer if they had done somthing with bitcoinj instead |
03:11:26 | Emcy_: | oh no it just creates a bitcoin URI QR and wants you to scan it with your phone |
03:17:33 | Luke-Jr: | lol |
03:32:25 | emsid: | so its not really integrated? |
03:51:53 | gmaxwell: | https://people.xiph.org/~greg/decentralized-time.txt |
03:58:03 | realazthat: | can the bitcoin keys be used for encryption as well as signing messages, theoretically? |
03:58:57 | realazthat: | I just watched Kevin Greene's presentation on BIP 70 |
03:59:43 | realazthat: | am thinking it can easily be modified to use bitcoin public keys to avoid SSL |
04:00:56 | tacotime: | I hope so, I'm using it for my ssh sessions :| |
04:01:24 | realazthat: | what? |
04:01:30 | tacotime: | Or is that just for signin? |
04:01:47 | realazthat: | you are using bitcoin keys to auth for ssh? |
04:02:16 | realazthat: | I never heard of that heh |
04:02:17 | tacotime: | No, you can use ecdsa keys as opposed to rsa keys though. |
04:03:26 | realazthat: | ah thats what you meant |
04:03:28 | realazthat: | yeah sure |
04:03:41 | realazthat: | I assume you can, I just want to know if there is any reason not to |
04:09:04 | tacotime: | I think you use ECDH to share a symmetric cipher... but that's not exactly what you're looking for. |
04:09:13 | tacotime: | *symmetric cipher key |
04:09:39 | tacotime: | I thought you could, but apparently I'm mistaken (unless no one else corrects me). |
04:13:15 | tacotime: | Yeah, that's what bitmessage uses https://bitmessage.org/wiki/Encryption |
04:14:50 | tacotime: | This thread gives an explanation, but I don't know if it's the correct one; https://bitcointalk.org/index.php?topic=238714.msg2528883#msg2528883 |
04:16:50 | tacotime: | bitcoin-wizards seems to be the place where i fill in all these gaps in my knowledge, heh. |
04:18:18 | Emcy_: | >nakamoto chain |
04:18:26 | Emcy_: | wow that seems obvious now |
04:19:42 | tacotime: | So when ssh is using ECDSA for auth and encryption, it's actually using ECDH for AES key exchange and ECDSA for signing the auth? |
04:23:08 | tacotime: | Apparently http://www.snailbook.com/docs/rfc5656.txt |
04:44:36 | realz: | tacotime: ah interesting |
04:55:24 | tacotime: | Looks like NDCoin is now trying to do the same thing as Ethereum |
04:55:46 | tacotime: | https://dl.dropboxusercontent.com/u/3133557/Bitcoin/Introducing%20NDcoin.pdf |
04:56:09 | tacotime: | And promising SCIP moon magic to make useful decentralized computing for proof of work |
05:04:16 | realazthat: | gah |
05:04:18 | realazthat: | did I split |
05:04:20 | realazthat: | tacotime: SCIP can be used to make almost *anything* a PoW algorithm |
05:04:56 | tacotime: | right. i'm waiting to see how zerocash fares first with it, though. |
05:05:05 | tacotime: | parameter sizes are still kind of daunting. |
05:06:14 | realazthat: | yeah, I am not sure how useful it would actually make a network |
05:06:34 | realazthat: | since, it would be wasting some constant at a minimum |
05:06:56 | realazthat: | so a network that wastes 10X resources to make 1X resource useful |
05:06:58 | realazthat: | it is useful |
05:07:05 | tacotime: | it's kind of been the cryptobuzzword as of late :P |
05:07:10 | realazthat: | but really, is that gonna save the planet |
05:07:14 | realazthat: | but it is cool |
05:07:20 | realazthat: | there are other uses aside from PoW |
05:07:26 | realazthat: | it is a very powerful concept |
05:07:46 | tacotime: | yeah |
05:07:46 | realazthat: | you can use other computers to prove things for you |
08:21:52 | gmaxwell: | realazthat: bitcoin public keys are worthless for that, not because of encryption or whatever, bip 70 doesn't need encryption or ssl. it uses x509 certs for human identity, because nothing else exists. |
08:23:30 | gmaxwell: | realazthat: I don't agree that "SCIP can be used to make almost *anything* a PoW algorithm" in fact, PCP only makes claims of the soundness of the proof not non-optimization and nothing else is anything better. |
08:23:50 | gmaxwell: | In theory— if the statement is true you can produce a passing proof without doing any work at all |
08:24:13 | Luke-Jr: | ? |
08:24:24 | gmaxwell: | (not that anyone knows how to do that generally since it would prove P=NP if it really was general) |
08:24:28 | Luke-Jr: | I think I agree with him about that maybe |
08:25:01 | Luke-Jr: | SCIP proves you did the work |
08:25:03 | Luke-Jr: | no? |
08:25:57 | gmaxwell: | no. It doesn't it proves the statement is true. |
08:26:26 | Luke-Jr: | what statement? |
08:27:22 | gmaxwell: | you have some thing that you're computing and you're proving for these inputs you got these outputs, for example. You can use a snark to prove that the outputs are the true outputs for the inputs... but they is no promise you did 'the work'. |
08:28:00 | gmaxwell: | maybe in practice no one currently knows how to optimize something under any particular zk-snark system, but there is no promise you cannot. |
08:28:16 | Luke-Jr: | well, doesn't that apply to SHA2 as well? |
08:29:25 | gmaxwell: | if the hash is sound you only get luck, were .. say for example you had a scip over a progrm that just made the output equal the input and had a busy loop in it. It seems very likely to me that you can optimize out actually computing the busy loop. |
08:29:57 | Luke-Jr: | sure |
08:30:38 | Luke-Jr: | but I took it to mean, the POW would be a fixed algorithm, and SCIP would only be used to prove that you got the right result (and implicitly, used the algorithm) |
08:30:40 | gmaxwell: | this applies to less trivial examples too. how less trival who knows. Probably whole advancements in approximation theory are waiting in this space. |
08:31:10 | gmaxwell: | okay sure, to make validation cheap.... but normally we want pow to not be trapdoored or overly optimizable. |
08:31:21 | gmaxwell: | e.g. someone finds an optimization to make it 100x faster... thats bad. |
08:31:33 | gmaxwell: | some people thought you could use scip to prove that you didn't optimize, but thats not so. |
08:31:44 | gmaxwell: | (or at least no guarenteed) |
08:42:54 | gmaxwell: | realazthat: 10x? more like 1000x. :P |
09:57:11 | DoogieHouser: | DoogieHouser has left #bitcoin-wizards |
10:09:49 | austinhill: | for those of you at dinner tonight, thanks - whay a great conversation |
10:10:14 | austinhill: | what |
10:35:59 | stonecoldpat: | ah is that why its so quiet here today? they are all hungover? |
10:41:40 | austinhill: | Hopefully no worse for the wear |
11:39:37 | airbreather_1: | airbreather_1 is now known as airbreather |
12:19:11 | edulix_: | edulix_ is now known as edulix |
13:10:04 | comboy: | gmaxwell: took me long enough but I run this histogram on your gox addresses, nothing interesting, same as prev just much less data, looking at these I'm not buying theory of 500k+ btc slowly escaping because of TM and automatic reissues |
14:35:43 | fanquake: | fanquake has left #bitcoin-wizards |
14:44:59 | comboy: | would be interesting to put it together with bitcoin days destroyed because of the latest statement and peak in bitcoin days destroyed in feb, but Im done with this stuff for now |
14:51:19 | realazthat: | gmaxwell: mmm bar sasson indicated that it was so to me in an email |
14:51:28 | realazthat: | gmaxwell: heh, I was giving some lower bound |
14:51:40 | realazthat: | but yeah, 1000x to 1x useful |
14:51:48 | realazthat: | whatever, a huge constant |
14:52:26 | realazthat: | ben* |
14:53:06 | realazthat: | "Is there a guarantee that there is no way to generate a signature if a correct answer is otherwise found in a quicker manner than running `P`, the original program, via running `Q` instead?" |
14:53:19 | realazthat: | A: "Yes, the only way (assuming you cannot break crypto) is to run P, not Q." |
14:53:36 | realazthat: | now, tbh I don't understand the crypto at all |
14:56:21 | andytoshi: | realazthat: i'd need to see a pretty solid argument for that claim, if you do an SHA256 outside of the POW, you know exactly how many iterations need to be done before finding the right hash. the claim that you can't make a proof of exactly that many iterations of the same program, without actually doing them under proof, is nontrivial |
14:56:33 | andytoshi: | interesting that ben-sasson makes that claim tho, thx for that |
14:57:13 | andytoshi: | iterations of the same code* |
15:11:58 | aksyn: | anyone looked to see if they can tie a gox address to a transaction with an nlocktime? obviously we wouldn't see the real one, but undoubtedly if mark were going to do this he would experiment first and might give us a rough timestamp on when he locked away his deep cold coins (if indeed that's what happened - i'm basing this on him saying they were not lost, but "inaccessible"). him using a lock_time seems more plausible to me than losing the privat |
15:11:59 | aksyn: | keys. |
15:12:39 | aksyn: | (i imagine the gox address would be a few hops away from the address where he did that experiment) |
15:13:12 | aksyn: | mining the blockchain I found 47 transactions using an epoch lock_time, and have a list of gox addresses (from reddit) - just wondered if anyone is going down the same path |
15:13:18 | aksyn: | *datamining |
15:22:16 | andytoshi: | aksyn: if mark is using an nlocktime tx to keep coins from himself (and i do not find this a likely story), he won't publish the tx until it can be mined |
15:22:36 | andytoshi: | oh, i see, you think there's an experiment one |
15:22:38 | aksyn: | andytoshi: i realise that, but you wouldn't just blindly do it without testing the theory |
15:22:44 | aksyn: | andytoshi: exactly |
15:23:10 | andytoshi: | i think that's worth looking that, i'd be curious about nlocktime use in general |
15:23:14 | aksyn: | andytoshi: he may have been doing it for security reasons, or for his personal stash, or maybe even some nefarious reason (like putting it 5-10 years in the future when any criminal action has gone away) |
15:24:33 | andytoshi: | what's cool (and more -wizardly) is that you can create single signatures where you don't know the privkey |
15:24:55 | andytoshi: | you sign with random data and calculate the pubkey from that (which will also be random) which makes the sig valid |
15:25:53 | andytoshi: | unfortunately you can't use this to locktime funds because you need to know the txid of your input, but to create the input tx you need to know the pubkey :( |
15:27:33 | andytoshi: | if we could reference inputs by txout instead of txid:index this would work, a totally secure way to lock funds from yourself. and you could make the signature be some nothing-up-my-sleeve number to prove to others that you don't possess the key |
15:27:43 | andytoshi: | s/don't possess/never possessed/ |
15:29:24 | andytoshi: | oh, never mind, even referencing by txout does not work. you'd need to somehow refer to a specific txout without knowing what it is beforehand |
15:32:17 | aksyn: | andytoshi: "you can't use this to locktime funds" - so.. what other use case is there? |
15:33:01 | aksyn: | andytoshi: that's an interesting idea, the txout one.. |
15:33:43 | wallet421: | wallet421 is now known as wallet42 |
15:34:31 | andytoshi: | aksyn: can't think of any 'real' uses off the top of my head, making uniformly random valid signatures may be useful for security proofs |
15:34:54 | andytoshi: | aksyn: but i figured out how you can locktime funds with this, tho you need a few more opcodes |
15:37:06 | andytoshi: | nvr mind, dammit. all i got was a twisted version of pay-to-pubkeyhash |
15:37:19 | andytoshi: | "pay-to-(r,s)-hash" |
15:44:56 | andytoshi: | if there was a signature type which simply did not sign its input reference, then we could lock funds this way. |
15:45:59 | andytoshi: | create a locktimed TX which does not sign its input reference, with a random ECDSA signature. compute the pubkey for the sig. spend to the corresponding address. use that spend as the input of the locktime'd tx |
16:50:01 | justanotheruser: | justanotheruser is now known as just[dead] |
17:52:16 | grau: | grau is now known as Guest70785 |
18:25:28 | gmaxwell: | realazthat: Alas, I think Eli might not have understood or thought it through, been ignoring cases where P and Q are black-box indistinguishable, or answering for the general case vs specific optimizations because I'm pretty sure this is not so. I can dig up some citations later. |
18:26:45 | gmaxwell: | Maybe in practice it would actually be fine (because the kinds of optimizations that would actually be interesting have no pratically obvious way to trick it anyways). |
18:42:10 | realazthat: | gmaxwell: ok |
18:42:22 | realazthat: | yes, that would make it substantially weaker I think |
18:42:26 | realazthat: | if you are right |
18:42:43 | realazthat: | it would mean you must use provably hard problems |
18:43:14 | realazthat: | still exciting tech |
18:44:00 | realazthat: | actually, I am thinking, |
18:44:22 | realazthat: | gmaxwell: wouldn't it be possible to have a hash of the state each step, |
18:44:30 | realazthat: | and the output would output the hash at the end |
18:44:43 | realazthat: | thus it would be practically provable that one went through the entire program |
18:44:44 | andytoshi: | realazthat: how do you verify that? |
18:45:06 | realazthat: | andytoshi: because SCIP will prove that it is the correct answer |
18:45:14 | realazthat: | because the hashing is itself *part* of the program |
18:45:20 | gmaxwell: | realazthat: consider my busy loop example, you could just run the hash instead of the busyloop for the part of the code where you detect the loop. |
18:45:21 | andytoshi: | ah, hmm |
18:45:45 | realazthat: | gmaxwell: right, but just running the hash in a busy loop pretty much proves that you ran it |
18:45:49 | realazthat: | I don't see a practical difference |
18:46:14 | gmaxwell: | Because it's just a very roundable way of doing POW at that point. The security is all in the hash. |
18:46:39 | realazthat: | gmaxwell: I agree it has no advantage over the current PoW, which is analgous to just doing the hash |
18:47:23 | andytoshi: | realazthat: how do you enforce people chaining hashes like this? what is the difference between starting a new miner and restarting the scip with a new nonce? |
18:47:29 | andytoshi: | (and searching for the nonce secretly outside of scip) |
18:47:45 | realazthat: | andytoshi: you start with a known input |
18:47:48 | realazthat: | that changes |
18:47:52 | realazthat: | like the last block hash |
18:47:58 | realazthat: | it changes the entire program state |
18:48:12 | andytoshi: | realazthat: but then you make it a race, you lose the memoryless property |
18:48:52 | realazthat: | oh wait I misunderstood your question |
18:49:05 | andytoshi: | it seems like conceptually if you want miners to be able to start/stop at any time without disadvantage, you can't enforce a long mining time in SCIP |
18:49:56 | realazthat: | mmm yeah, requires pondering |
18:50:02 | gmaxwell: | (well also, it enforces sequentialness, which means its not progress free...) |
18:50:18 | realazthat: | another point to consider, |
18:50:25 | realazthat: | is that the only "useful" work would be part of the chain |
18:50:30 | realazthat: | all the other work is thrown away |
18:50:45 | realazthat: | so thats a terrible other 1/1000X + factor |
18:51:27 | realazthat: | what I once dreamed about was a computation market |
18:51:31 | realazthat: | where people would put up jobs |
18:51:38 | realazthat: | and the miners would do the jobs |
18:51:42 | realazthat: | and get paid |
18:51:59 | realazthat: | and then, the block reward would go to one of the miners randomly |
18:52:15 | realazthat: | so all the work wouldn't be wasteful |
18:52:28 | realazthat: | but yeah, there are lots of practical issues with it |
18:52:29 | andytoshi: | realazthat: there is a conceptual problem there, suppose i give a miner a graph to find a 3-coloring of |
18:52:43 | andytoshi: | but secretly i know a 3-coloring, i created the graph to have one, and i give this to the miner who i'm colluding with |
18:53:05 | andytoshi: | then he gets the coins for 'guessing' a 3-coloring |
18:53:14 | realazthat: | andytoshi: right, but if SCIP proved that the miner actually *RAN* the entire program |
18:53:27 | realazthat: | then knowing the answer wouldn't help |
18:53:52 | realazthat: | but I see your point |
18:53:55 | realazthat: | people would give themselves jobs |
18:54:01 | realazthat: | to play in the lottery |
18:54:16 | andytoshi: | then you'd be forcing people to do things in the most inefficient way, and it could still be gamed anyway |
18:54:44 | realazthat: | andytoshi: the efficiency would move to making the SCIP implementation very efficient |
18:55:00 | realazthat: | but yeah, it would be forced to run the algorithm as given |
18:55:01 | andytoshi: | ok, but you've lost the usefulness benefit. if i invent some crazy 3-coloring heuristic, i'd like to join this market and clean up with it. |
18:55:20 | andytoshi: | but now i can't. only if i invent a way to optimize SCIPs for POW |
18:55:23 | amiller: | PoW isn't the right abstraction, you want it to be random and incremental like lottery tickets |
18:55:42 | realazthat: | andytoshi: right, it is up to the employer to find the good algorithm, it is true that they can't compete in the type of algorithm |
18:55:57 | realazthat: | andytoshi: but if they *could* compete for the right algorithm, then ofc that defeats the PoW aspect |
18:57:01 | gmaxwell: | realazthat: while you're here— how far did you get with doing tinyram in llvm? |
18:57:20 | realazthat: | gmaxwell: I have an interpreter, but nothing usable in LLVM |
18:57:43 | gmaxwell: | realazthat: odd question: how big did your tinyran interpreter turn out to be? |
18:57:58 | gmaxwell: | er tinyram |
18:58:07 | realazthat: | code size? |
18:58:11 | realazthat: | it is pretty trivial |
18:58:11 | gmaxwell: | yea. |
18:58:43 | realazthat: | are you interested in it |
18:58:56 | realazthat: | I can polish it up a bit and put the code up next week |
19:00:27 | gmaxwell: | Sure. |
19:01:40 | amiller: | in case anyone's interested, i've written a mathematical security definition I call "scratch-Off puzzles", distinct from "proof-of-work puzzles", that captures the memory-free / progress-free properties you've been mentioning |
19:02:57 | andytoshi: | i would definitely be interested in that, i'd like some concrete security definitions for my alts.pdf |
19:03:14 | amiller: | andytoshi, let me show you it, i have to find it somehwre |
19:08:22 | goeaijrgo: | better then paying for a lottery ticket? beastie boys" you have got to be in it to win it?" |
19:10:36 | goeaijrgo: | goeaijrgo has left #bitcoin-wizards |
19:29:52 | maaku_: | realazthat: that would be good to see (tinyram) |
19:30:30 | realazthat: | maaku_: its just an interpreter |
19:30:43 | realazthat: | an LLVM backend would be good to see :D |
19:40:18 | maaku_: | gmaxwell: what would be the benefit of the decentralized time at that accuracy? |
19:43:17 | maaku_: | also you're talking about location determination on a solar system scale, right? do ou think it'd be accurate enough for geolocation? |
19:57:59 | gmaxwell: | maaku_: the last bit was a bit of a wanky lark, with enough SNR you could do geolocation but the solar system is almost entirely colinear so the system of equations would likely be very poorly conditioned and even with good SNR (not going to happen) it probably wouldn't actually work. |
19:58:33 | gmaxwell: | But I thought worth mentioning because it was a fun idea, and is theoretically possible even if the engineering wouldn't work out in practice. It's the sort of thing you could probably get a military grant to just try. |
19:59:37 | phantomcircuit: | gmaxwell, good morning |
20:00:08 | gmaxwell: | maaku_: wrt time— we seem to want to have very accurate time, it gets used for many things, like embargoed announcements that have market impact so that people can't do latency advantaged HFT arb. ... but the existing ways are centeralized, and thats unfortunate. |
20:14:48 | azariah4: | gmaxwell: How do you mean the solar system is almost entirely colinear? |
20:15:34 | azariah4: | maaku_: gmaxwell not sure what the exact discussion was about, but something worth noting is that with e.g. SPICE you can convert between various solar system time systems with high precision |
20:15:45 | gmaxwell: | well, 'coplanar' |
20:16:30 | gmaxwell: | azariah4: read the link from last night, some old silly whitepaper I wrote that had come up in dinner discussion |
21:21:07 | dickson.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
21:21:07 | dickson.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot antephialtic cpacia rdymac Krellan_ wallet42 nsh adam3us roidster grau jtimon_ _ingsoc Luke-Jr HM CodeShark sl01 OneFixt pajarillo spinza petertodd heakins a5m0 @ChanServ optimator ryan-c Manfred__ wangbus ageis coryfields pigeons Sorcier_FXK jarpiain Krellan grzs bobke BitCoroner crucif0rm BlueMatt perrier_ poggy matrixfox amiller comboy harrow area nanotube Ryan52 forrestv gmaxwell K1773R nOgAnOo EasyAt hno mmozeiko |
21:21:07 | dickson.freenode.net: | Users on #bitcoin-wizards: Alanius_ sipa keus weex d34th azariah4 zacm warren otoburb helo Graet trn wumpus tromp_ copumpkin Fistful_of_Coins imsaguy sirius_ oooooo mappum maaku_ kinlo midnightmagic phantomcircuit thrasher iddo crescendo samson_ emsid espes__ aksyn c--O-O Sangheil- kanzure_ edulix Hunger- Emcy_ michagogo|cloud just[dead] rs0 gribble eristisk Logicwax jron tucenaber DBordello UukGoblin realazthat airbreather roasbeef austinhill shinybro__ jcorgan |
21:21:07 | dickson.freenode.net: | Users on #bitcoin-wizards: jrmithdobbs Ursium so DougieBot5000 Muis shesek |
21:30:01 | just[dead]: | just[dead] is now known as justanotheruser |
21:31:43 | indico: | anyone know of a tool that will sort blocks n through m by bitcoin days destroyed ? |
21:38:40 | indico_: | sorry, was disconnected. if anyone know of any code let me know thanks |
21:53:21 | ens_: | ens_ is now known as ens |
21:59:12 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 240 seconds)) |
22:00:50 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
22:08:43 | kornbluth.freenode.net: | topic is: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
22:08:43 | kornbluth.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot zzyzx Dizzle _ingsoc rs0 c0rw1n mappum__ OneFixt kill\switch indico_ ens rdymac nanotube nsh Luke-Jr HM CodeShark sl01 pajarillo shesek Muis DougieBot5000 so Ursium jrmithdobbs jcorgan shinybro__ austinhill roasbeef airbreather realazthat UukGoblin DBordello tucenaber jron Logicwax eristisk gribble justanotheruser michagogo|cloud Emcy_ Hunger- edulix kanzure_ Sangheil- c--O-O aksyn espes__ emsid samson_ crescendo iddo |
22:08:43 | kornbluth.freenode.net: | Users on #bitcoin-wizards: thrasher phantomcircuit midnightmagic kinlo maaku_ oooooo sirius_ imsaguy Fistful_of_Coins copumpkin tromp_ wumpus trn Graet helo otoburb warren zacm azariah4 d34th weex keus sipa Alanius_ mmozeiko hno EasyAt nOgAnOo K1773R gmaxwell forrestv Ryan52 area harrow comboy amiller matrixfox poggy perrier_ BlueMatt crucif0rm BitCoroner bobke grzs Krellan jarpiain Sorcier_FXK pigeons coryfields ageis wangbus Manfred__ ryan-c optimator @ChanServ |
22:08:43 | kornbluth.freenode.net: | Users on #bitcoin-wizards: heakins petertodd |
22:11:23 | azariah4: | gmaxwell: like this part "However, we can instead us another globally |
22:11:27 | azariah4: | available reference signal which is strongly attack resistant: The sun" |
22:11:43 | gmaxwell: | You were supposted to chuckle there. |
22:12:08 | azariah4: | the idea is brilliant, and reflection from the sun on objects is not the only useful reference signal |
22:12:18 | azariah4: | starts also works, after all star navigation can be quite precise |
22:12:22 | azariah4: | *stars |
22:12:57 | gmaxwell: | yea, I mention that you can use any available osc. There must be enough variation to time off it. Pulsars would work great but they require far too much equipment to detect. |
22:13:44 | gmaxwell: | but you can also potentially use things like the electrical grid within an area.. or any mutually observable radio transmission, even if you can't decode it. |
22:14:15 | azariah4: | hehe yepp, it's a good starting point for generic sensor input |
22:14:32 | azariah4: | one, perhaps more realistic application, could be distributed weather sensors |
22:14:38 | gmaxwell: | The sun was just a fun example because unlike GPS it's awful hard to turn off. |
22:14:51 | gmaxwell: | (we hope!) |
22:14:54 | azariah4: | not sure if there is really a attack scenario worth having a blockchain for that, but it could be useful |
22:15:19 | maaku_: | gmaxwell: giant sun-shades... |
22:16:15 | azariah4: | one could imagine using a combination of GPS, Galileo and Compass for less centralized satellite input |
22:16:36 | maaku_: | gmaxwell: also, it's quite simple to put up a reflector bird which makes the sun's EM signature measurable from the night sky (2-3 birds in a mid-earth orbit) |
22:16:44 | azariah4: | though of course they could still all conspire to attack nodes |
22:16:48 | maaku_: | azariah4: all are trivially simple to jab |
22:16:52 | maaku_: | *jam |
22:17:44 | gmaxwell: | maaku_: but _much_ easier to correlate against. |
22:18:25 | maaku_: | gmaxwell: yeah but I like the properties of using the sun as a source of randomness |
22:20:00 | maaku_: | but I wonder just how random it is - could you make short term predictions, even if somewhat inaccurate |
22:20:08 | gmaxwell: | maaku_: I've never actually tested it— in theory it should work... but it might be hard to find an observation channel with a good enough ratio of sun noise to background noise to make it work well. |
22:20:46 | gmaxwell: | it doesn't have to be random, e.g. if the sun put out a sinewave it would be fine so long as you had a way to get your initial time to get you within one cycle of the wave. |
22:21:32 | maaku_: | besides timestamping though, it's interesting to think what you can do with a globally available random oracle |
22:21:57 | azariah4: | http://en.wikipedia.org/wiki/Pyranometer |
22:22:05 | gmaxwell: | well sadly, many of those cool things require bit exact decisions and thats hard to get from an unstructured analog signal. |
22:22:52 | gmaxwell: | one of the other reasons that sun is interesting is that a huge portion of its output power is light, and it's cheap to make a really really high gain anteann for light.. so you can be super selective against jamming, if you don't mind a rig to track the sun. |
22:23:33 | azariah4: | the rig could be combined with a solar panel though |
22:23:51 | maaku_: | he engineering challenges are interesting .. you'd probably want to select spectra which reflect well off the lunar surface |
22:23:54 | azariah4: | bundled with one for people who already would invest in one perhaps? |
22:24:23 | maaku_: | * maaku_ is discussing with adam3us potential uses for a random beacon/oracle |
22:26:47 | gmaxwell: | maaku_: yea, basically I think it would be interesting to setup a light sensor in two different cities with gpsdo for timing, and measure the correlation of the sun signals at different wavelengths. Its a measurement I've never made, but I have a pair of gpsdos (somewhere) if you know anyone who wnats to make it. |
22:28:13 | gmaxwell: | I think you can extract somewhat reliable bits via a procedure which measures the lag time of peak self-similarity in the sun signals, and decodes it with an error correcting code so that if you get a few bits different you still get the same fingerprint. |
22:29:46 | ens: | light jamming? |
22:30:29 | ens: | "get out of the way, you're jamming the sun" |
22:31:15 | azariah4: | good point, the gpsdo could be placed near sunbathing enthusiasts to reduce chance of a jamming attack |
22:31:42 | ens: | lymann-alpha based intergalactic positioning system. |
22:32:22 | ens: | accuracy of about ~5 light years for civilian usage. |
22:37:39 | wallet421: | wallet421 is now known as wallet42 |
22:38:16 | petertodd: | pigeons: yeah, they're hiring me to do a security audit, as well as another person in the bitcoin world (dunno if the info on who it is is public) |
22:40:32 | petertodd: | pigeons: mastercoin also doesn't work with multisig (although it's not a security issue) I got them to disable it, and re-enabling it will be the first real-world test of the embeded consensus system upgrade procedure I wrote about |
22:41:47 | spin123456: | spin123456 is now known as spinza |
22:56:33 | tacotime: | tacotime is now known as tacotime_ |
22:59:11 | justanotheruser: | justanotheruser is now known as just[dead] |