| 01:04:14 | rajaniemi.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 |
| 01:04:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: andy-logbot arubi KingCoin Sangheili Aquent2 jgarzik vaxzine moa Dr-G Emcy maclane aburan28 Cory vmatekol_ tromp_ jtimon phedny myeagleflies JohnnyBitcoin mkarrer devsaturn justanotheruser peterlie artifexd Kireji Luke-Jr fenn wallet42 wiretapped dansmith_ MoALTz mortale pen Graftec mmozeiko c0rw1n d4de^^ hashtag Adlai Starsoccer spiftheninja waxwing dansmith_btc drawingthesun nsh_ emsid DoctorBTC [7] altoz phantomcircuit arowser1 |
| 01:04:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: NikolaiToryzin Starduster bbrittain a5m0 Alanius iddo erizo Max_H3adr00m kinlo poggy sl01 maaku [d__d] Nightw0lf samson_ nuke1989 devrandom jaekwon Fistful_of_coins rfreeman_w LaptopZZ SDCDev OneFixt Grishnakh gnusha HM_ @ChanServ lechuga_ abc56889 throughnothing harrow fluffypony mr_burdell Apocalyptic so ahmed_ Gnosis Keefe pajarillo roasbeef ryan-c otoburb helo [Tristan] TD-Linux catcow danneu coryfields btc_ crescendo amiller Eliel |
| 01:04:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: zibbo_ jbenet mappum yoleaux firepacket jrayhawk_ Hunger-- Muis Kretchfoop tromp michagogo @gwillen BlueMatt smooth CodeShark digitalmagus BrainOverfl0w BigBitz petertodd bobke heath kumavis K1773R hguux dgenr8 lnovy _2539 kanzure Taek gmaxwell sipa pigeons [\\\] coryfields_ warren comboy [Derek] Iriez Krellan Dyaheon nsh livegnik berndj wumpus optimator_ LarsLarsen Meeh burcin nanotube HaltingState shesek MRL-Relay gribble wizkid057 EasyAt |
| 01:04:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: zenojis tacotime Graet asoltys pi07r CryptOprah epscy espes__ Anduck artilectinc copumpkin hollandais midnightmagic Logicwax go1111111 spinza SomeoneWeird napedia gavinandresen forrestv stonecoldpat weex_ Guest89609 |
| 01:04:44 | Aquent2: | Aquent2 is now known as Aquent |
| 01:11:47 | andytoshi: | sigh, 657 lines of missed scrollback ... i was only out for a day :) |
| 01:11:48 | yoleaux: | 22 Oct 2014 22:47Z andytoshi: what do you think? https://github.com/kanzure/bitcoin-incentives/issues/4 |
| 01:13:52 | nsh: | if it's any consolation, when you missed it, it was just scroll |
| 01:16:39 | andytoshi: | :) |
| 01:38:08 | lechuga_: | whats the proper nomenclature for a non-winning chain with a shared root with the most-work chain |
| 01:38:24 | lechuga_: | i used to call them sidechains :/ |
| 01:39:04 | andytoshi: | lechuga_: "path from a stale to the main chain" :P |
| 01:39:19 | kanzure: | was that an orphan fork? |
| 01:39:28 | kanzure: | oh, stale. yes. |
| 01:39:48 | lechuga_: | into stalechain |
| 01:40:16 | sipa: | side branches? |
| 01:40:22 | sipa: | stale chains? |
| 01:40:38 | sipa: | they're most often (incorrectly) called orphan blocks/chains |
| 01:40:41 | lechuga_: | side branches might be confusing |
| 01:41:04 | lechuga_: | stale sort of implies they were once fresh |
| 02:09:37 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 02:12:43 | maaku: | maaku is now known as Guest56072 |
| 02:16:01 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 02:24:43 | lechuga_: | should a demo federated peg chain be expected shortly |
| 02:29:17 | Luke-Jr: | lechuga_: I think I read on reddit someone saying they had basically the same thing going on for some other project - other than that, it might be a bit; what do you consider "shortly" and what counts as a "demo"? :P |
| 02:29:53 | lechuga_: | lol no rush |
| 02:30:04 | lechuga_: | was just curious if i should expect something in th enext couple weeks |
| 02:30:14 | lechuga_: | given the contracthashtool coming out too |
| 02:30:27 | BlueMatt: | lechuga_: ofc we're working on initial betas, but I think the plan is to build initial, shitty tests which we use to inform our designs when we start working on public implementations |
| 02:30:45 | lechuga_: | makes sense |
| 02:31:09 | jeremyrubin: | Hmm anyone know of any interesting bitcoin related security proposals? Looking for a class project. |
| 02:31:29 | BlueMatt: | lechuga_: ofc with our already-public stuff (+/-) you can do a meat-based sidechain already :) |
| 02:31:40 | andytoshi: | jeremyrubin: what level of schooling are you talking about? and can you be more precise "security proposal"? |
| 02:31:42 | BlueMatt: | (ie non-automated transfers) |
| 02:31:55 | lechuga_: | lol@meat-based |
| 02:32:24 | jeremyrubin: | Grad level MIT network security class |
| 02:32:30 | gmaxwell: | lechuga_: demo? yes. Hurray for permissionless tech. (thus the public commitment tool) |
| 02:33:00 | kanzure: | amiller: petertodd: maybe instead of talking about a single giant consensus it should be mutually overlapping consensus between all of the connected/networked/interoperating participants. afterall, it's only meaningful within the context of two unrelated third parties or something (like, if you assume everyone is honest, then your entire model can collapse into some centralized non-bitcoin implementation anyway). |
| 02:33:02 | jeremyrubin: | Could also involve some OS level hacking |
| 02:33:32 | lechuga_: | nice |
| 02:33:36 | andytoshi: | jeremyrubin: hmmm...so there is a big open problem about formalizing the security properties of proof-of-work...probabl not a class project |
| 02:33:46 | andytoshi: | jeremyrubin: there are some trustless gambling proposals that i think are implementable |
| 02:34:10 | andytoshi: | jeremyrubin: might wanna poke around http://bitcoin.ninja |
| 02:35:38 | andytoshi: | jeremyrubin: https://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt is a modification to monero that gmaxwell and i have been thinking about. what's written there is implementable but probably a way bigger task than a class project |
| 02:35:46 | andytoshi: | since the monero codebase is not super accessible i hear |
| 02:36:42 | andytoshi: | i guess, how crypto-heavy do you want to be? if you want to do security but not crypto i should shut up, i don't think about that too much |
| 02:36:43 | BlueMatt: | votes on if https://github.com/Blockstream/contracthashtool qualifies as interesting enough for bitcoin.ninja? |
| 02:36:53 | andytoshi: | ack |
| 02:37:15 | jeremyrubin: | (reading up on bitcoin.ninja) |
| 02:37:15 | lechuga_: | as if it only has 5 stars |
| 02:37:29 | kanzure: | BlueMatt: this isn't a democracy, and you shouldn't judge by start count. |
| 02:37:47 | lechuga_: | guess it wasnt really publicized was it? |
| 02:37:54 | lechuga_: | i only saw the link to the repo here |
| 02:37:55 | andytoshi: | ..ah yet it's up to 7 since lechuga_ commented :P |
| 02:38:02 | lechuga_: | nice! |
| 02:38:08 | BlueMatt: | not particularly, I'm more asking independantly of sidechains |
| 02:38:16 | BlueMatt: | its much more general |
| 02:38:16 | kanzure: | BlueMatt: also how about something like https://github.com/unsystem/paypub or https://github.com/zw/PoLtree/ or https://github.com/petertodd/python-merbinnertree |
| 02:38:38 | BlueMatt: | we should have a software section on bitcoin.ninja |
| 02:38:48 | kanzure: | or https://github.com/petertodd/timelock |
| 02:39:20 | kanzure: | i dunno if this is a good implementation or not but it might be worth poking at https://github.com/olalonde/proof-of-liabilities |
| 02:39:39 | andytoshi: | +1 to everything kanzure just suggested (kanzure you should make a pr) |
| 02:40:01 | kanzure: | would a frontend js app to do shamir secret sharing stuff be relevant? |
| 02:40:35 | andytoshi: | i nak mainly to keep the software section from dwarfing the rest :P |
| 02:40:42 | kanzure: | eg http://seedguardian.github.io/ |
| 02:40:47 | kanzure: | kk |
| 02:41:07 | BlueMatt: | the only sharmir's implementation I like is my own :p |
| 02:41:07 | andytoshi: | i think olalonde's thing should be there, if it is broken hopefully people will ask here. i think it's being used |
| 02:41:14 | BlueMatt: | but, yea, thats not particularly wizaardly |
| 02:44:22 | BlueMatt: | * BlueMatt is not so sure that python-merbinnertree is that wizardly |
| 02:44:30 | BlueMatt: | its just a datastructure...not very bitcoin-specific? |
| 02:44:54 | andytoshi: | hmm, yeah, the wizardly part of it is petertodd's name |
| 02:45:00 | BlueMatt: | heh |
| 02:45:05 | andytoshi: | so i change to nak :) |
| 02:45:12 | BlueMatt: | well, pt has done other wizardly things... |
| 02:45:25 | Prints_: | Prints_ has left #bitcoin-wizards |
| 02:45:34 | gmaxwell: | sure, the random PT tools, and the contract hash tools sure. |
| 02:46:16 | gmaxwell: | I have a ton of old shit on bct thats just posted for prior art establishment... that I should go dredge up, some is pretty good. |
| 02:47:12 | kanzure: | https://github.com/TheBlueMatt/bitcoinninja/pull/9 |
| 02:47:13 | kanzure: | https://github.com/TheBlueMatt/bitcoinninja/pull/8 |
| 02:47:23 | BlueMatt: | damn, was already doing that... |
| 02:47:36 | kanzure: | you can't beat me http://www.seanwrona.com/typeracer/profile.php?username=kanzure |
| 02:47:57 | gmaxwell: | (uh by pretty good I mean ideas that are potentially useful) |
| 02:49:26 | gmaxwell: | Someone want to go write up the statistical arguments for http://people.xiph.org/~greg/simple_verifyable_execution.txt ? I'll rain praise down on you for doing that... it's really only meant as an educational tool, not as something secure or usable... but it would be better with some concrete reasoning on the security. |
| 02:49:46 | andytoshi: | kanzure: btw i have your -incentives pr open in my browser, i will try to read over it tomorrow. i am heading out of town for a short while, will probably get to it on the plane. (not sure, i have a bunch of school stuff i need to read in the next week to get back on track after the blockstream wp blitz) |
| 02:49:59 | kanzure: | andytoshi: no rush |
| 02:50:07 | kanzure: | andytoshi: let me know if you need a ride to/from the airport |
| 02:50:33 | andytoshi: | kanzure: thx a ton. but i'm an eight-minute walk from the 100 shuttle route |
| 02:50:40 | amiller: | so i've been thinking.... actually i guess this is zooko's idea.... sidechains might be a lot more useful if you could process *some* of the transaction rules of the side chain |
| 02:50:43 | amiller: | but for performance reasons ideally not all of them |
| 02:50:56 | andytoshi: | kanzure: will bug you in the next couple weeks, we should meet up in any case |
| 02:50:57 | amiller: | this could address that scary problem where the 51% attacker on a sidechain can make a false transaction and take all the pegged bitcoins |
| 02:51:14 | amiller: | even simple limits like not too much taken in one day for example |
| 02:51:24 | kanzure: | andytoshi: okie dokie |
| 02:51:44 | gmaxwell: | amiller: yea sure, first time they were discussed in here I think that was mentioned. Also ... my coinwitness post bascially just takes about the form where you verify all their rules under a snark. Really for the vision of complete freedom in what you can do, you need to give that up (ignoring snark pixie dust). |
| 02:52:21 | andytoshi: | (also any other -wizards in austin should be aware that kanzure and i are, and can often be free to meet people) |
| 02:52:36 | gmaxwell: | one trade of there is that you have to expose a lot more data (Again, assuming no pixie dust) ... which ruins all the succinctness and any application around getting some scalablity gains. |
| 02:52:38 | amiller: | gmaxwell, i don't see how if you can't do all of them that means you shouldn't be able to do any of them |
| 02:53:46 | gmaxwell: | amiller: doing almost any of them immediately breaks succenctness.. so... :meh: plus the engineering to get it right is harder (I'm not opposed, just explaining why we didn't spend any space discussing that subset of designs in the paper... it would probably merit some more exploration) |
| 02:55:04 | gmaxwell: | goodnight... 6am to 8pm the next day.. wee.. |
| 02:55:07 | amiller: | this all-or-nothing succinctness seems too hasty to me, seems like there might be a useful spectrum |
| 02:55:24 | amiller: | gmaxwell, i think your thing looks like cut-and-choose malicious-secure yao garbled circuits |
| 03:07:47 | amiller: | http://eprint.iacr.org/2010/284.pdf Secure Two-Party Computation via Cut-and-Choose Oblivious Transfer |
| 03:09:23 | amiller: | oops i didn't mean that one http://link.springer.com/chapter/10.1007/978-3-540-72540-4_4#page-1 An Efficient Protocol for Secure Two-Party Computation in the Presence of Malicious Adversaries |
| 03:09:43 | kanzure: | paperbot: http://link.springer.com/chapter/10.1007/978-3-540-72540-4_4#page-1 |
| 03:10:38 | paperbot: | http://diyhpl.us/~bryan/papers2/paperbot/9dac56417e2ec6e8716ed3a3ce945f8d.txt |
| 03:11:51 | Taek: | nifty |
| 03:12:15 | kanzure: | doesn't always work, lacks omnipotence.. |
| 03:14:25 | Taek: | my browser isn't rendering the page, just some html. Don't see the abstract either. |
| 03:14:51 | kanzure: | normally paperbot fetches a pdf, but dumps html into text when it fails as a half-way debug log. this means it doesn't have access. |
| 03:15:40 | amiller: | kanzure, deserves an archivist award of some kind. |
| 03:15:52 | kanzure: | anyway here we go http://diyhpl.us/~bryan/papers2/paperbot/An%20Efficient%20Protocol%20for%20Secure%20Two-Party%20Computation%20in%20the%20Presence%20of%20Malicious%20Adversaries.pdf |
| 03:15:55 | amiller: | like msot the time i find a paper on google scholar its a link to his site |
| 03:16:10 | kanzure: | unfortunately gmaxwell yet again has me beat on this subject haha |
| 03:16:19 | BlueMatt: | heh |
| 03:23:52 | fanquake_: | fanquake_ is now known as fanquake |
| 03:28:44 | wyager: | wyager has left #bitcoin-wizards |
| 03:42:30 | kanzure: | amiller: here's the rest of that conference-series-thing (still incoming, give it 20 minutes for the rest) http://diyhpl.us/~bryan/papers2/security/advances-in-cryptology/ |
| 03:44:39 | Luke-Jr: | * Luke-Jr wonders if libblkmaker belongs on bitcoin.ninja impl list |
| 04:07:58 | maclane: | q |
| 04:24:56 | maaku: | maaku is now known as Guest6823 |
| 04:25:25 | lechuga_: | how does minting work on the federated peg sidechain |
| 04:25:36 | lechuga_: | every1 is aware of the federations public keys and whatever they say goes? |
| 04:27:01 | sipa: | lechuga_: one way is just assigning 21M BTC in the sidechain to the federation (which is a multisig script, composed of the federation's keys) |
| 04:27:25 | sipa: | which then takes the position of all not-transferred bitcoins |
| 04:30:50 | lechuga_: | how will the nonce be provided to the federation |
| 04:31:02 | sipa: | TCP? |
| 04:31:25 | sipa: | or it is just part of the claim transaction you make to unlock the coins on the sidechain |
| 04:31:52 | lechuga_: | and that channel is out of scope? |
| 04:33:23 | sipa: | ? |
| 04:35:09 | lechuga_: | i guess im asking what does the claim tx look like |
| 04:37:40 | sipa: | it's a transaction that takes coins from that 'stash' and transfers a part to you |
| 04:37:53 | sipa: | it's a completely normal transaction in case of that 21M preassignment |
| 04:38:58 | lechuga_: | from bitcoin to sidechain is a multisig p2sh tx but the keys have been deterministically adjusted by a nonce |
| 04:39:05 | lechuga_: | right? |
| 04:39:12 | sipa: | it's the same on the other side |
| 04:39:36 | sipa: | on the bitcoin side it's to the federation, on the sidechain it's from the federation |
| 04:45:25 | lechuga_: | and then how do they come back |
| 04:46:20 | sipa: | send to the federation on the sidechain, and take from the federation on the other side |
| 04:47:23 | lechuga_: | "take" means the federtion manually creates a bitcoin tx to your spk? |
| 04:48:00 | sipa: | or you do, and ask the federation to sign it for you |
| 04:52:48 | lechuga_: | but going to the sidechain the federation doesn't need to sign anything do they? |
| 04:56:26 | btcwizkid: | Sidechains: I'm not sure how blockstream etc get past the problems Peter Todd cited... |
| 04:59:18 | lechuga_: | isnt the risk of the federation colluding pretty high |
| 05:00:11 | kanzure: | wasn't there a non-federated proposal somewhere? |
| 05:01:16 | lechuga_: | that's OP_SIDECHAINPROOFVERIFY i think |
| 05:04:03 | sipa: | kanzure: well, our whitepaper... |
| 05:06:03 | sipa: | using a DMMS for securing transfers is what is proposed in the main body; using a federated peg instead is explained in an appendix |
| 05:21:10 | lechuga_: | sorry, had to reread 3.2 |
| 05:22:18 | Luke-Jr: | lechuga_: risk of a 15-of-15 in different countries run by different entities would be low |
| 05:22:52 | Luke-Jr: | could go even lower if you split the keys.. |
| 05:23:15 | Luke-Jr: | as long as all parties to key-parts are in the room observing the destruction of the PC generating it |
| 05:23:24 | Luke-Jr: | and there's no savant that can memorise it instantly |
| 05:23:35 | lechuga_: | lol |
| 05:25:55 | sipa: | 15-of-15 has much higher risk for key loss than theft :p |
| 05:26:19 | kanzure: | Luke-Jr: man now you're going to make me try to memorize that sort of thing instantly |
| 05:28:22 | Luke-Jr: | sipa: beside the point XD |
| 05:29:20 | sipa: | just avoid all false sense of security and use 15-of-14, which is equivalent to 15-of-15 with one lost key |
| 06:07:40 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 06:10:13 | bbrittain_: | bbrittain_ is now known as bbrittain |
| 06:10:34 | Iriez: | sidechain's sure have kicked the hornets nest |
| 06:10:45 | Iriez: | I've not seen dev's this picky at each other in quite some time. |
| 06:10:53 | Iriez: | * Iriez popcorn |
| 06:15:51 | maaku: | maaku is now known as Guest33913 |
| 06:17:20 | kinlo_: | kinlo_ is now known as kinlo |
| 06:21:58 | Guest33913: | Guest33913 is now known as maaku |
| 06:38:44 | BlueMatt: | Iriez: huh? |
| 07:10:37 | lechuga_: | trying to understand what the special output is going to look lke |
| 07:10:42 | lechuga_: | like* |
| 07:11:53 | lechuga_: | and what the corresponding input looks like on the sidechain |
| 08:05:15 | sendak.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:15 | sendak.freenode.net: | Users on #bitcoin-wizards: andy-logbot Adlai paveljanik mmozeiko profreid Max_H3adr00m [7] austinhill1 Sangheili pen kinlo KingCoin erizo Alanius aburan28 a5m0_ iddo_ emsid Meeh sl01_ bbrittain poggy_ lnovy moa mapppum Greed Luke-Jr superobserver RoboTeddy btcwizkid Dr-G zoltron5 spinza fanquake warptangent paperbot c0rw1n_ mortale wiretapped devrandom Graftec phantomcircuit PaulCapestany DougieBot5000 andytoshi jgarzik Emcy Cory vmatekol_ tromp_ phedny myeagleflies |
| 08:05:15 | sendak.freenode.net: | Users on #bitcoin-wizards: JohnnyBitcoin devsaturn justanotheruser artifexd fenn dansmith_ d4de^^ Starsoccer spiftheninja waxwing dansmith_btc drawingthesun altoz arowser1 NikolaiToryzin Starduster [d__d] Nightw0lf samson_ nuke1989 Fistful_of_coins rfreeman_w LaptopZZ SDCDev OneFixt Grishnakh gnusha @ChanServ lechuga_ abc56889 throughnothing harrow fluffypony mr_burdell Apocalyptic so ahmed_ Gnosis Keefe pajarillo roasbeef ryan-c otoburb helo [Tristan] TD-Linux catcow |
| 08:05:15 | sendak.freenode.net: | Users on #bitcoin-wizards: danneu coryfields btc_ crescendo amiller Eliel zibbo_ jbenet mappum yoleaux firepacket jrayhawk_ Hunger-- Muis Kretchfoop tromp michagogo @gwillen BlueMatt smooth CodeShark digitalmagus BrainOverfl0w BigBitz petertodd bobke heath kumavis K1773R hguux dgenr8 _2539 kanzure Taek gmaxwell sipa pigeons [\\\] coryfields_ warren comboy [Derek] Iriez Krellan Dyaheon nsh livegnik berndj wumpus optimator_ LarsLarsen burcin nanotube HaltingState MRL-Relay |
| 08:05:15 | sendak.freenode.net: | Users on #bitcoin-wizards: gribble wizkid057 EasyAt zenojis tacotime Graet asoltys pi07r CryptOprah epscy espes__ Anduck artilectinc copumpkin hollandais midnightmagic Logicwax go1111111 SomeoneWeird napedia gavinandresen forrestv stonecoldpat weex_ Guest89609 HM_ |
| 08:09:26 | maaku: | maaku is now known as Guest22397 |
| 08:10:43 | Guest22397: | Guest22397 is now known as maaku |
| 09:54:53 | justanotheruser: | justanotheruser is now known as justanot1eruser |
| 09:55:04 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 10:24:53 | nsh: | oh, there's an AMA |
| 10:25:05 | nsh: | "Update: Adam Back, Greg Maxwell, Pieter Wuille and the other authors of the sidechain paper will be conducting an AMA on Reddit, October 23, 2014 at 9:00 am PDT. Please join!" |
| 10:25:36 | nsh: | .date |
| 10:25:39 | nsh: | .time |
| 10:25:54 | nsh: | today then |
| 10:27:09 | gandalf: | does it make sense for a small dht to have a blockchain? |
| 10:27:29 | gandalf: | let's say a network has multiple dhts and each dht has a blockchain |
| 10:27:53 | gandalf: | in a case where very node must be kepet fully connected to another node in the dht |
| 10:29:15 | nsh: | gmaxwell had discussed (with cjd of cjdns) a DHT using a blockchain to control entry/membership as a DoS-prevention mechanism |
| 10:29:25 | nsh: | not sure of any other proposed hybrid systems |
| 10:32:00 | gandalf: | can snarks theoretically replace blockchains? |
| 10:33:27 | gandalf: | ethereum people made claims that decentralized autonomous corporations are the first step towards AI |
| 10:34:04 | gandalf: | but with the current speed for confirmations i don't think this will ever be the case. |
| 10:38:08 | Luke-Jr: | ugh, I should have slept |
| 10:38:18 | Luke-Jr: | gotta be up for 6+ more hours… |
| 10:39:56 | justanotheruser: | I don't see how DACs are a step towards AI, let alone the first |
| 10:49:01 | Luke-Jr: | https://gitorious.org/geneticchat <-- first was in 2009? :P jk |
| 10:51:29 | nsh: | heh |
| 11:39:59 | kanzure: | http://arxiv.org/pdf/1410.6079v1.pdf "It turns out that by exploiting a Bitcoin built-in reputation based DoS protection an attacker is able to force specific Bitcoin peers to ban Tor Exit nodes of her choice." |
| 11:41:24 | kanzure: | "a totally virtual Bitcoin reality" well that's one way of saying it |
| 11:44:25 | kanzure: | http://rjlipton.wordpress.com/2014/10/18/a-new-provable-factoring-algorithm/ |
| 11:44:25 | justanotheruser: | interesting |
| 11:44:40 | justanotheruser: | re: blocking exit nodes |
| 11:45:27 | justanotheruser: | seems DoSing tor would be more expensive than blocking enough exit nodes from every client to partition the network |
| 11:46:00 | justanotheruser: | s/more/less |
| 11:46:11 | kanzure: | i suspect the more lucrative tor-related shennanigans will be inside the tor network itself, like correlating bitcoin traffic with tor traffic |
| 12:20:58 | a5m0_: | a5m0_ is now known as a5m0 |
| 15:04:11 | Nightw0lf: | Nightw0lf is now known as Nightwolf |
| 16:49:28 | mortale_: | mortale_ is now known as mortale |
| 16:50:18 | werxh2: | werxh2 has left #bitcoin-wizards |
| 17:37:47 | lechuga_: | can any1 explain to me what the special output will look like? |
| 17:38:05 | lechuga_: | i feel like im being obtuse |
| 17:39:06 | lechuga_: | sidechains.pdf remins me of reading bitcoin.pdf prior to seeing any code |
| 17:39:12 | lechuga_: | reminds* |
| 17:39:28 | zooko: | Heh. |
| 17:48:57 | helo: | might it be ~optimal to have one main sidechain off of bitcoin directly that is designed to have sidechains branched off of it? |
| 17:50:27 | helo: | (in reference to adam's AMA post, "It needs a recursive sidechain because there are more constraining requirements to return peg to bitcoin main. By having a side-chain to return to it can have features to facilitate more advanced things.") |
| 17:50:31 | Luke-Jr: | helo: that's the plan at the moment |
| 17:51:42 | helo: | is blockstream geographically centralized? |
| 18:26:16 | maaku: | no |
| 18:26:47 | maaku: | lechuga_: there are many options for what the output would look like, which is why we didn't go into details |
| 18:27:35 | kanzure: | is there a way to preserve the current distribution of bitcoin in the blockchain on a sidechain, such that bitcoin would be locked on the sidechain from inception? |
| 18:27:41 | lechuga_: | maaku: thx. it would've helped my little brain to see one option maybe at the level of the appendix A detail |
| 18:27:41 | kanzure: | s/bitcoin/assets |
| 18:27:46 | maaku: | helo: we have people in five countries on two contenents |
| 18:27:54 | kanzure: | erm, i meant s/bitcoin would be locked/assets would be locked |
| 18:27:57 | lechuga_: | but i can appreciate this is maybe obvious for the intended audience of the whitepaper |
| 18:28:54 | maaku: | lechuga_: we had that in an earlier draft but were worried that people would latch onto it as our proposed structure, when it really was a just a toy example |
| 18:29:07 | maaku: | there's a lot of in-the-weeds details to be worked out for an actual output structure |
| 18:29:15 | lechuga_: | i live in weeds :) |
| 18:29:22 | lechuga_: | that's fair |
| 18:29:30 | lechuga_: | would've loved to see that toy example tho |
| 18:31:01 | helo: | kanzure: you mean a coinbase transaction to a sidechain? |
| 18:31:07 | maaku: | i think iirc it involved OP_SPV_PROOF_VERIFY, but one of the things to be worked out was the exact details of its parameters |
| 18:31:27 | lechuga_: | that's where i get hungup |
| 18:31:47 | lechuga_: | and because of that i feel like the paper describes roughly half of a design (which probably isn't fair to say) |
| 18:32:44 | kanzure: | helo: no. i mean something like "some way to import all bitcoin, but disable them, such that if the main chain loses hashpower over time, that people who were not awake during the transition to the sidechain, can safely recover their bitcoin later" |
| 18:33:25 | kanzure: | by which i mean, if the sidechain does not merge changes upstream into bitcoin itself |
| 18:34:16 | Taek: | maaku: if you had included an example in the whitepaper, I probably would have latched into it in a way that you didn't intend. So it's probably good that you left things vague. |
| 18:34:38 | kanzure: | hmm, my question is not specific enough |
| 18:35:25 | helo: | kanzure: i think that's possible |
| 18:36:13 | helo: | for example, a sidechain that used some form of lamport signature scheme would be a nice place to stash long-term bitcoin if you were afraid of quantum computing |
| 18:36:25 | kanzure: | that's not what i mean |
| 18:37:14 | kanzure: | specifically i mean to enumerate the scenarios where there might be a temporal proof lockout time, that may not have been originally intended, but that otherwise might happen, as a result of someone not waking up on the bitcoin blockchain and forming a proof to transfer into the sidechain. |
| 18:38:51 | kanzure: | i am still being vague i think. |
| 18:39:21 | amiller: | i received a comment from gun sirer (the cornell selfish mining professor) that "the paper is lovely but makes the quintessential mistake of saying: first david chaum invented ecash, then there was bitcoin" and nothing in between. |
| 18:39:51 | kanzure: | in terms of cypherpunk memory i think that's how people legitimately remember it :) |
| 18:40:29 | amiller: | i'm not really even sure what i'd prioritize adding to cover more ground in a short review. |
| 18:40:32 | lechuga_: | reading the paper and having that be your key-takeway seems odd |
| 18:40:52 | kanzure: | did he offer some references? |
| 18:41:41 | amiller: | let me see what sort of stuff he cites in selfish mining paper |
| 18:43:11 | amiller: | from majroity is not enough selfish mining paper "Decentralized digital currencies have been proposed before Bitcoin, starting with [11 chaum ecash] and followed by peer-to-peer currencies, e.g. [12 karma (gun sirers paper) ,13 PPay micrpyaments for p2p systems], and see [14 Zerocoin,4 Bitter to Better FC '12] for short surveys. |
| 18:43:41 | kanzure: | amiller: i should make a tool to expand silly "First Name, Last Name, Journal" citations into full citations with abstracts. because i've spent way too much time looking at a reference, only to later find out that i had read the paper before but only remembered the name. :( |
| 18:43:49 | amiller: | so... karma, ppay, i can imagine other examples might be like peppercoin and a few other things that basically never were proposed, may have had a startup around them, but never really took off. |
| 18:44:07 | amiller: | kanzure, indeed |
| 18:44:12 | kanzure: | ppay's architecture didn't seem very interesting to me. i only saw a few sentence review though. |
| 18:44:30 | kanzure: | ppay http://ilpubs.stanford.edu:8090/592/1/2003-31.pdf |
| 18:45:41 | kanzure: | "A broker is required ... [for] double spending protection" well why bother |
| 19:07:24 | gmaxwell: | funny wrt chaum, many of the people who reviewed and worked on the paper worked on earlier digital currency systems. We weren't trying to suggest they didn't exist... it was mostly showing the start and then the lack of success to point out that the decenteralization was an essential part. |
| 19:25:17 | c0rw1n_: | c0rw1n_ is now known as c0rw1n |
| 19:35:10 | woah: | So is the desire for sidechains primarily driven by people's existing Bitcoin monetary investments? |
| 19:40:31 | kanzure: | no, there are many security benefits to understanding why hashpower and scarcity tend to be concentrated on a single chain |
| 19:42:16 | sipa: | woah: the reasoning is that there is no need for multiple digital currencies with free-floating exchange between eachother, as sidechain allow us to have different technologies running the same currency |
| 19:42:35 | woah: | but what's wrong with a free-floating exchange rate? |
| 19:42:49 | woah: | i mean, you can get the mining benefits with aux-pow or merged mining |
| 19:43:14 | woah: | without messing with the exchange rates. seems people just want to lock in their btc investments |
| 19:44:13 | sipa: | how is having two currencies, which are technically completely identical, better than having one? |
| 19:44:46 | poggy_: | poggy_ is now known as poggy |
| 19:44:50 | gavinandresen: | (sarcasm on) : more money! Means we’re all richer! (sarcasm off) |
| 19:44:54 | woah: | currency is somewhat of an analog for power |
| 19:45:10 | kanzure: | woah: do you know why multiple pow chains doesn't work? |
| 19:45:23 | kanzure: | multiple non-merge-mined pow chains |
| 19:45:29 | woah: | why not? |
| 19:46:03 | kanzure: | assume that it doesn't for a moment. wouldn't you agree that's an example of a motivation not driven by bitcoin monetary investments? |
| 19:46:43 | woah: | yes, but the concept of PoW itself has huge problems |
| 19:47:04 | woah: | anyway, sorry, not trying to troll |
| 19:47:08 | woah: | i'll give it a rest |
| 19:48:03 | amiller: | i am starting to like thinking of other analogies for a sidechain, such as the treasury account of a corporation... the sidechain is the (digital autonomous etc) corporation and the bitcoins pegged into it are its funds |
| 19:48:34 | amiller: | the currency on the sidechain could be like the stocks of the corporation or like other instruments like the flyer miles etc |
| 19:49:02 | amiller: | the bitcoin reserve fund of the sidechain could be used to pay out dividends to the share holders at arbitrary times, it could be given out in a raffle, etc. |
| 19:49:58 | amiller: | there's no technical need to have some kind of units on the sidechain that represent transferable units of the reserve currency |
| 19:50:19 | amiller: | also: you could easily have a sidechain with multiple parents |
| 19:50:27 | woah: | hmm cool |
| 19:50:44 | kanzure: | yes clearly bitcoin is too simple and what we really need is a blockgraph |
| 19:50:48 | woah: | but the parents must be pegged to each other right? |
| 19:50:49 | kanzure: | (/sarc) |
| 19:50:56 | amiller: | the parents don't need to be pegged to each other at all no |
| 19:51:53 | amiller: | my dissenting opinion w.r.t. the whitepaper is conflating the mechanism (using spv-ish proofs to have one blockchain control funds on another blockchain) with one of many possible applications "2 way peg" |
| 19:52:12 | sipa: | amiller: sidechains vs pegged sidechains :) |
| 19:52:22 | sipa: | though admittedly we do not mention any other use cases |
| 19:52:43 | amiller: | sure... but the "technique" in the paper is referred to as "pegging" which i think is just slightly misleading |
| 19:53:17 | amiller: | sipa, the freicoin is a reasonable example but still basically involves "exchange rates" so i think it gets readers to assuming there's some kind of restriction that isn't actually technically there |
| 19:54:35 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:46:34 | anirgu: | anirgu has left #bitcoin-wizards |
| 20:54:49 | sl01_: | is there a simple way to cryptograpically prove you control a certain # of bitcoins outputs at a block # w/o disclosing the addresses/outputs? is this the same thing or related to the proof of reserve stuff that some exchanges use? |
| 20:55:46 | nsh: | number or value? |
| 20:55:48 | gwillen: | sl01_: the proof of reserve stuff I've seen involves the exchange proving ownership of specific outputs (the thing that it doesn't reveal is the balances of the individual users) |
| 20:56:03 | sl01_: | nsh: number of (total) bitcoins |
| 20:56:14 | nsh: | * nsh nods |
| 20:57:02 | sl01_: | effectively proving to someone you hold a certain amt of value w/o people being able to start stalking/investigating/doxxing you |
| 20:57:17 | gwillen: | this is basically what zerocoin did (I'm not following what those folks are doing now) |
| 20:57:20 | moa: | sl01_: i think the exchanges are signing messages with the keys associated with addresses containing bitcoins ... |
| 20:57:34 | nsh: | * nsh thinks |
| 20:57:36 | gwillen: | you would lock some coins in exchange for a proof that you own a certian number of coins, without having to reveal which ones went in |
| 20:59:16 | nsh: | you could do through coinswaps |
| 20:59:35 | nsh: | but you'd need people to do it with, which decreases the utility |
| 21:02:27 | nsh: | *coinjoins |
| 21:04:20 | sl01_: | yea i mean if you have a way to mix that you can trust you can just sign w the actual outputs and then go mix them afterwards, effectively accomplishing the same goal, but i was wondering if there was an offline way to do it |
| 21:05:18 | nsh: | * nsh nods |
| 21:05:31 | nsh: | i don't think so but could be stupid |
| 21:05:54 | nsh: | well |
| 21:06:33 | sl01_: | i wonder what practical things could be accomplished with that other than anonymous bragging... |
| 21:08:25 | nsh: | even if you could, you'd only be demonstrating the ability to spend all the outputs at one point in time (which you can timestamp) but that's no guarantee some weren't spent immediately after |
| 21:08:36 | sl01_: | yea |
| 21:08:50 | sl01_: | that still says something |
| 21:08:54 | nsh: | right |
| 21:13:53 | eyegore: | eyegore has left #bitcoin-wizards |
| 22:13:49 | petahash: | hello |
| 22:17:25 | amiller: | 'lo |
| 22:22:14 | petahash: | whats doing |
| 22:37:28 | petahash: | apparently something is happening tomorow with the SEC rumours? |
| 22:50:20 | sl01_: | petahash: tomorrow something is happening with the SEC, or with the SEC rumors (are they being modified)? |
| 22:51:20 | petahash: | these are rumours and stupid rumours if not true |
| 22:51:49 | gmaxwell: | petahash: probably the wrong channel for your questions. |
| 22:52:06 | Taek: | is there a blockstream related channel? |
| 22:52:07 | gmaxwell: | (but I have no clue what you're talking about but highly doubt they're related to this channel) |
| 22:52:19 | petahash: | thank you, i will change the topic |
| 22:52:22 | gmaxwell: | Taek: not currently. |
| 22:59:41 | amiller: | gmaxwell, did you look at that cut & choose yao garbled circuits paper that i think is the same as your simple secure computation thing |
| 23:36:05 | IHB: | I hope all is well guys. Is there a channel specifically related to the decentralized vs centralized debate in regards to bitcoin mining? |
| 23:41:20 | nsh: | IHB, probably here if it's theoretical |
| 23:42:44 | nsh: | there is #bitcoin-mining too, but i'd guess it's more practically orientated and perhaps a bit noisy |
| 23:44:08 | IHB: | yes it is. i am still fleshing out some thoughts. i have been reading lots of info and wanted to see if i could connect with someone who knows more than me on this topic. in no way am i a newbie to mining or how it works, i consulted at cointerra for a bit to actually get an insider look at how the sausage is made. i have a very strong opinion now and wanted reallt test my theory with someone. look for an expert on this topic wh |
| 23:44:42 | kanzure: | you are suffering from irc message length cutoff and should fix your client |
| 23:47:56 | lechuga_: | or fix your CR frequency |
| 23:49:12 | IHB: | i would rather keep them short. but of course will look into how to fix it if i really find the need to type more |
| 23:59:16 | jgarzik: | IHB, Just say your theory out loud :) |