| 00:13:36 | HM_: | gmaxwell, isn't the crux of the problem that bitcoind is both a blockchain information server and a user wallet manager? |
| 00:14:45 | HM_: | i don't think moving SSL out of the daemon makes any sense until there's nothing sensitive flowing to and from it |
| 00:14:59 | phantomcircuit: | HM_, sort of |
| 00:15:16 | phantomcircuit: | the daemon is sensitive |
| 00:15:39 | phantomcircuit: | the consensus state is itself sensitive, doubly so if you have a wallet that trusts it |
| 00:16:06 | gmaxwell: | HM_: lol sort of the opposite. SSL should be out of it because SSL is an epic failure security disaster n-times in the running. |
| 00:16:31 | HM_: | but authentication is another matter. |
| 00:16:54 | gmaxwell: | Really the RPC is intended to be used locally, the SSL is not a default thing; and is a PITA to setup. |
| 00:17:30 | HM_: | there's "am i authorized to use this wallet" user auth, and then there's "i am the blockchain/consensus thingy you want to trust" auth between the client and the daemon |
| 00:17:44 | gmaxwell: | "Insanity: doing the same thing over and over again and expecting different results." |
| 00:18:35 | phantomcircuit: | gmaxwell, it's good that ssl is annoying to setup |
| 00:18:44 | phantomcircuit: | otherwise people would try to use it on public interfaces |
| 00:18:48 | HM_: | I take it bitcoind can't run as a Windows system service for instance, and then expect different users to be able to use the GUI to use their wallets? |
| 00:19:03 | phantomcircuit: | HM_, not today, maybe soon |
| 00:19:36 | HM_: | cool |
| 00:19:44 | gmaxwell: | HM_: have you like.. not ever used the software? |
| 00:19:57 | HM_: | not for like... 2 years? |
| 00:19:59 | gmaxwell: | the "GUI" is not a front end on it, its a monolithic program, and an either or today. |
| 00:20:29 | gmaxwell: | Seperation will probably result in the wallet being made a SPV client to the daemon, so there is less of an authentication issue there. |
| 00:20:53 | HM_: | sure, so authentication is implicit in being able to decrypt the wallet db |
| 00:22:17 | HM_: | It doesn't sound like you're going to need anything protecting the RPC at that point unless you want to be able to issue shutdown commands. |
| 00:22:39 | HM_: | or mess with peers, like trusted or preferred peers. |
| 00:23:19 | gmaxwell: | which RPC are you talking about there? Because if the wallet were seperate there would be two rpcs. |
| 00:23:34 | HM_: | why? |
| 00:23:45 | gmaxwell: | ... |
| 00:23:56 | gmaxwell: | Because 90% of the things people do with the RPC is talk to the wallet. |
| 00:24:21 | HM_: | right, but why do you need an RPC between the GUI and the wallet, that can be monolithic? |
| 00:24:38 | HM_: | (or compiled against a library) |
| 00:25:01 | phantomcircuit: | HM_, wallet communicates with full node using p2p protocol as an spv client |
| 00:25:06 | gmaxwell: | sure that would be but ... surprise there are a great many people who use bitcoin that are not using the GUI. ... uh like every single merchant service. |
| 00:25:19 | kanzure: | separation of concerns, there's no reason for a wallet frontend to have to strongly consider p2p protocol stuff, for example |
| 00:25:20 | phantomcircuit: | you would authenticate that connection |
| 00:25:26 | gmaxwell: | HM_: I've enjoyed your contribtions in the past but like.. come on, actually use the software please. Testnet coins are free. |
| 00:25:35 | phantomcircuit: | doing that the security of the spv wallet is equal to that of a full node wallet |
| 00:27:39 | HM_: | Why would a merchant service need an RPC if they were using a 'libwallet' library that let them interact safely with encrypted wallets and establish connections to the daemon? |
| 00:27:57 | HM_: | effectively you put the client library in to all your nodes |
| 00:31:11 | HM_: | oh I see, SPVs communicate via the P2P protocol to get block headers |
| 00:31:33 | HM_: | no I was referring to the 'trusted peer' model for client-server separation |
| 00:34:33 | gmaxwell: | HM_: there isn't a great reason to introduce yet another externally visible protocol, we already have a client protocol... one that tends to have pretty good security properties. |
| 00:34:52 | gmaxwell: | e.g. even a malicious server can only do so much to it. |
| 00:34:59 | HM_: | another protocol? |
| 00:35:25 | gmaxwell: | gmaxwell has left #bitcoin-wizards |
| 00:36:17 | HM_: | Wallet on disk <---> user GUI <--- RPC --> bitcoind <-----> P2P network is what I was suggesting, so the user interface trusts bitcoind entirely |
| 00:36:33 | HM_: | no SPV |
| 00:40:11 | phantomcircuit: | user GUI <--- RPC --> bitcoind |
| 00:40:13 | phantomcircuit: | nooooo |
| 00:40:40 | HM_: | i think you're suggesting you put authentication in to the P2P network so people can run SPV and decide set which nodes to trust with confidence? |
| 00:41:48 | HM_: | phantomcircuit, why not? |
| 00:44:29 | phantomcircuit: | HM_, authenticated spv |
| 00:44:41 | phantomcircuit: | limit trust between components without significant additional cost |
| 00:44:46 | phantomcircuit: | simply the system, dont complicate it |
| 00:45:34 | moa: | simplify? |
| 00:45:45 | phantomcircuit: | reduce complexity |
| 00:45:57 | phantomcircuit: | modularize |
| 00:46:00 | phantomcircuit: | magicify |
| 00:46:02 | phantomcircuit: | etc |
| 00:46:07 | moa: | awesome |
| 00:46:53 | moa: | consultants gotta make a living too though |
| 00:48:01 | HM_: | phantomcircuit, so if I want to integrate bitcoin payments in to a game right now, I have to put my private key in to bitcoinds hands and then use the RPC |
| 00:48:15 | HM_: | (or use a 3rd party payment solution) |
| 00:48:21 | HM_: | how is that a simplification? |
| 00:49:42 | moa: | what's a perfectly good protocol without additional layers of kruft and jargon to make it "user-friendly" and "human-readable"? ... probably worthless |
| 00:51:24 | phantomcircuit: | HM_, you're taking the wallet code out of bitcoind |
| 00:51:32 | HM_: | phantomcircuit, yup |
| 00:51:50 | HM_: | what's it needed in there for? bloom filtering? |
| 00:52:04 | phantomcircuit: | but that allows you to then go and remove additional code in bitcoind which basically only exists to support the wallet code |
| 00:52:16 | HM_: | sounds good? |
| 00:52:23 | phantomcircuit: | it is good |
| 00:55:26 | HM_: | the insinuation right now is that SPV clients are light enough to embed everywhere |
| 00:55:43 | HM_: | i don't think that's the case |
| 00:56:47 | HM_: | if i have an Android game that takes payments for things, i'm not going to embed an SPV client in to it... i'll just go use Googles payment solution |
| 00:57:26 | maaku: | HM_: why would you have an SPV client in the game? |
| 00:57:52 | maaku: | there should be an SPV client running on the phone, yes, with a service API exposed to the game |
| 00:59:44 | HM_: | exactly |
| 01:00:25 | maaku: | maybe i'm confused. that counts as embedding in my book (it's on the device) |
| 01:01:36 | HM_: | Google don't make to talk HTTP to use In-app billing |
| 01:01:52 | HM_: | the SPV client isn't an app on a phone, it's a system service |
| 01:02:19 | HM_: | alternatively run it on a remote machine and authenticate to it |
| 01:02:24 | HM_: | (e.g. a full node) |
| 01:02:40 | HM_: | that way it doesn't need to eat battery |
| 01:03:02 | HM_: | my tuppence anyway |
| 01:07:16 | HM_: | not everyone keeps their PC on 24/7 like me ;) but i quite like the idea of my phone using SPV while i'm on the move but a home run full-node while I'm connected to my home wifi |
| 01:08:25 | HM_: | you can't do that right now without toggling the trusted peer settings in Andreas's app |
| 01:08:35 | HM_: | and that doesn't offer any solution to other apps on your phone |
| 01:16:09 | HM_: | ...meh |
| 01:16:16 | HM_: | apparently Andreas does have a library |
| 01:24:26 | HM_: | oh well, i guess I need to go away and read :P |
| 02:14:14 | tacotime: | etlase finally released his whitepaper http://www.decrits.net/decrits-consensus.pdf |
| 02:14:45 | penny: | penny is now known as Guest69779 |
| 02:15:46 | tacotime: | i still don't comprehend it |
| 02:18:29 | kanzure: | this proposal looks like one that was thoroughly debunked in here |
| 02:18:46 | kanzure: | regarding some set of signers that collude and knowing the state of all blockchains or something |
| 02:19:29 | tacotime: | "Like Bitcoin’s genesis block, the Decrits software will contain a genesis CB that contains a list of public keys in the VL representing the initial Voices of the network. In lieu of anonymous POW, these Voices are tasked with creating and protecting the network history." |
| 02:19:35 | tacotime: | um... hm. |
| 02:19:46 | kanzure: | yeah this is in the logs somewhere. |
| 02:20:50 | tacotime: | the original thread is long and somewhat incomprehensible https://bitcointalk.org/index.php?topic=189239.0 |
| 02:21:23 | tacotime: | and features epic keyboard battles between anonymint and etlase |
| 02:22:39 | moa: | who are possibly the person? |
| 02:22:48 | moa: | the same person |
| 02:23:00 | tacotime: | moa: that seems like a reasonable conclusion |
| 02:31:41 | moa: | who's doing the work on putting uxto hash in block headers? ... and is there a github branch or similar yet? |
| 02:34:30 | moa: | https://bitcointalk.org/index.php?topic=204283.0 ... this? |
| 02:59:09 | maaku: | moa: me, when I have time to work on it |
| 02:59:22 | maaku: | (raised funds ran out, have some support from blockstream to do this, but not a priority) |
| 02:59:56 | maaku: | re code, there's a hashmap branch on my github that needs rebasing |
| 03:00:11 | maaku: | and some rework with lessons learnt |
| 03:01:15 | moa: | maaku: ah, thanks thought so ... this is related also https://github.com/bitcoin/bitcoin/pull/3977 ? |
| 03:01:30 | maaku: | yes that is the commitment mechanism I'd prefer |
| 03:01:48 | maaku: | results in deterministic overhead in proof size |
| 03:03:20 | maaku: | i separated it out because there are other proposals which benefit from it, e.g. appdx b of the sidechains paper |
| 03:03:37 | moa: | i see |
| 03:05:14 | moa: | interesting stuff |
| 03:05:35 | maaku: | seems like it needs a rebase; i'll do that now |
| 03:05:49 | moa: | i'll take it for a test drive |
| 03:11:33 | maaku: | #3977 i mean |
| 03:11:37 | maaku: | the hashmap stuff is unfinished |
| 03:13:00 | moa: | yep |
| 03:44:17 | maaku: | moa: pushed |
| 03:46:47 | moa: | k |
| 03:53:57 | maaku: | maaku is now known as Guest27454 |
| 03:55:33 | Guest27454: | Guest27454 is now known as maaku |
| 05:39:03 | penny: | penny is now known as Guest54023 |
| 07:22:35 | [\\\\]: | [\\\\] is now known as [\\\] |
| 09:05:17 | weber.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 |
| 09:05:17 | weber.freenode.net: | Users on #bitcoin-wizards: andy-logbot AaronvanW lmatteis torsthaldo Flyer33 bosma Dizzle__ [\\\] fanquake iddo todays_tomorrow Adlai coinheavy prodatalab Guest54023 TheSeven aburan28 maaku SDCDev c0rw1n Aquent1 justanotheruser jaekwon_ nuke1989 austinhill bobke_ moa cbeams shesek sneak napedia huseby bryanvu devrandom Baz__ GnarSith mortale stonecoldpat Anduck BananaLotus eric tacotime cryptokeeper Fistful_of_coins K1773R wallet42 HaltingState kefkius copumpkin Keefe |
| 09:05:17 | weber.freenode.net: | Users on #bitcoin-wizards: PRab Emcy_ CodeShark heath johndoe01_ helo phedny iambernie zwischenzug MRL-Relay fluffypony berndj samson_ phantomcircuit spinza kyletorpey Luke-Jr waxwing zenojis mmozeiko PaulCapestany pi07r btcdrak digitalmagus fragiletag midnightmagic sl01 nsh wizkid057 Muis Alanius Guest1930 arowser LarsLarsen go1111111 sipa poggy NikolaiToryzin cfields coryfields Sangheili mappum hollandais jbenet epscy kjj21__000 DoctorBTC Taek EasyAt warptangent Hunger- |
| 09:05:17 | weber.freenode.net: | Users on #bitcoin-wizards: optimator_ Starduster kumavis andytoshi dgenr8 BrainOverfl0w fds4345 gazab Iriez bbrittain BigBitz Apocalyptic emsid Starsoccer throughnothing warren tromp_ null_radix gavinandresen dansmith_btc Meeh Nightwolf AdrianG Logicwax mr_burdell Eliel zibbo_ tromp SomeoneWeird kgk pigeons nanotube Grishnakh lnovy asoltys weex_ kanzure gribble Krellan kinlo a5m0 superobserver artifexd fenn [d__d] LaptopZZ gnusha HM_ espes__ CryptOprah Graet burcin |
| 09:05:17 | weber.freenode.net: | Users on #bitcoin-wizards: livegnik _2539 hguux petertodd smooth BlueMatt @gwillen michagogo jrayhawk_ yoleaux amiller crescendo btc_ danneu catcow TD-Linux [Tristan] otoburb ryan-c roasbeef pajarillo Gnosis ahmed_ so harrow abc56889 lechuga_ @ChanServ wumpus myeagleflies Dyaheon firepacket |
| 12:03:17 | xplice: | hello world |
| 13:30:46 | wallet421: | wallet421 is now known as wallet42 |
| 14:06:52 | cbeams_: | cbeams_ is now known as cbeams |
| 14:19:28 | Aquent1: | Aquent1 is now known as Aquent |
| 14:36:16 | ericp4: | ericp4 is now known as eric |
| 14:54:35 | cryptokeeper: | hey guys..... question |
| 14:54:44 | cryptokeeper: | best pool to use? ease of use and payouts/etc... ? |
| 14:54:46 | cryptokeeper: | p2pool? |
| 14:54:58 | sipa: | #bitcoin |
| 14:57:06 | altoz_: | altoz_ is now known as altoz |
| 16:36:08 | penny: | penny is now known as Guest8974 |
| 16:40:01 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 16:54:21 | tacotime: | there is another claimed zerocoin implementation in the wild, which the implementing group claims to have gotten proof verification down to almost nothing and also proof sizes are said to be very small. https://bitcointalk.org/index.php?topic=846471.msg9447042#msg9447042 |
| 16:54:25 | tacotime: | but it seems strange |
| 16:55:00 | tacotime: | "Are you improving any aspects of the original zerocoin in other ways? in what ways exactly? Using the RSA modulus from world renowned RSA factoring challenge of unknown factorization" |
| 16:55:04 | tacotime: | um, yeah. |
| 16:55:36 | stonecoldpat: | i would have been more impressed, if they released the guy-fawkes coin implementation, considering what day it is |
| 16:56:01 | tacotime: | heh. |
| 16:56:04 | maaku: | one does not merely reimplement zerocoin |
| 16:56:48 | stonecoldpat: | tacotime: just their release notes: Release date: November 5th, 2014 (Guy Fawkes Day), 12:00 PM EST. |
| 17:09:19 | maaku: | maaku has left #bitcoin-wizards |
| 17:24:27 | devrandom: | devrandom is now known as devrando2 |
| 17:24:32 | devrando1: | devrando1 is now known as devrandom |
| 17:31:37 | bsm117532: | A while ago someone made the statement that bitcoin's ledger convergence (agreement) is a function of (transmission time)/(block time) which must be a small number. Does anyone know any document describing this more mathematically? e.g. an analysis of how small this number must be? |
| 17:47:40 | justanotheruser: | bsm117532: ~1/100 blocks are reorged, so that fraction is probably approximately that (6sec/600sec) |
| 17:48:55 | justanotheruser: | s/reorged/reorged out/ |
| 17:49:09 | bsm117532: | Where 6s is the time to receive a new block on average? |
| 17:49:28 | justanotheruser: | For miners at least |
| 17:56:20 | bsm117532: | Which comes down to the fact that mining is a flat probability distribution, so 1/100 of the time someone can generate a PoW small enough that it doesn't get transmitted to all nodes in time. |
| 17:57:34 | bsm117532: | What I'm thinking about is modifying the target difficulty so that it's a function of time. (Specifically, a sigmoid with high difficulty at short times and low difficulty at long times, with the crossover being the usual 10 minutes). This would effectively prevent these reorgs by making them require exponentially more work. |
| 17:57:39 | justanotheruser: | a PoW small enough? |
| 17:58:03 | bsm117532: | small enough hash. |
| 17:58:40 | justanotheruser: | how would the smallness of the hash be related to it not being transmitted in time? |
| 17:59:26 | bsm117532: | Because mining has a flat probability distribution, there's a 1% chance of generating a block with a hash 100 times smaller than the target difficulty. |
| 17:59:42 | justanotheruser: | this wouldn't work. People would just manipulate their timestamps so they would require the minimal amount of work |
| 18:01:40 | bsm117532: | But no one would accept those blocks until after that timestamp, and someone else will generate a block faster than you, winning the coinbase reward. |
| 18:02:24 | bsm117532: | So blocks with a manipulated (too-long = low difficulty) timestamp would not be accepted. |
| 18:03:26 | justanotheruser: | getting time to be perfectly aligned is difficult. Thats why your block can be up to two hours in the future according to the timestamp |
| 18:03:32 | gmaxwell: | bsm117532: ::sigh:: I thought we'd already gotten you to agree that the network is not synchrnous and not everyone has synchronized clocks, unless you admit centeralization. ... plus it will be accepted later if they do? |
| 18:04:24 | justanotheruser: | anyways, having a changing difficulty like that would probably cause miners to either mine a block with a certain timestamp in the future or not mine until they've hit that point in the future. |
| 18:04:25 | bsm117532: | The network doesn't have to be synchronous. But I don't have to accept your block until after my local clock says its timestamp is in the past. |
| 18:04:45 | justanotheruser: | bsm117532: sure, but that would leave you out of consensus |
| 18:04:49 | gmaxwell: | Beyond that, the bar you should be thinking of is not "Can I possibly make this work?", it's more like "How can I show this is free from attack/optimization/shortcut/etc." |
| 18:05:10 | bsm117532: | gmaxwell: of course. ;-) |
| 18:07:56 | gmaxwell: | bsm117532: in particular attackers aren't synch with the network, so I can go simulating a fake chain away from the network with warped time claims and roll the dice for much more 'apparent work' than the honest network. |
| 18:08:13 | bsm117532: | time-based difficulty would drive everyone to want to agree on clocks, and there's exactly one clock everyone can agree upon. Attackers could manipulate NTP but there are other clock sources. |
| 18:09:16 | gmaxwell: | There really aren't any cryptographically strong time sources generally available at all on the internet. So you're ending up requiring participants to have special hardware (and then even gps/glonass can send any time they want) |
| 18:09:36 | gmaxwell: | but thats not the point I was making. |
| 18:09:46 | bsm117532: | gmaxwell: yes. If you want to be insulated against network time manipulation. |
| 18:10:33 | bsm117532: | I'm trying to imagine how an attacker could generate a fake chain with more "apparent work" under this proposal. |
| 18:10:52 | gmaxwell: | You can go in the _other_ direction to claim faster blocks than you actually had, and thereby have a non-trivial probabity of getting lucky and reorgnizing the chain. (assuming you're counting the expected work; if not then there is another attack in simulation). |
| 18:11:12 | gmaxwell: | by making their difficulties much higher than the honest network's. |
| 18:11:44 | gmaxwell: | the work in the expenectation is the same, but the probablity you got a lucky roll is non-negligible. |
| 18:12:46 | gmaxwell: | bsm117532: come on, you really don't want to be doing this altcoin stuff; it's left you dependant on this community for free consulting, and then you're going to be going off and creating something which competes with bitcoin? lame. |
| 18:13:07 | bsm117532: | Heh how do you know what I'm working on? ;-) |
| 18:13:13 | kanzure: | relentless stalking |
| 18:13:24 | gmaxwell: | bsm117532: because you told me before. |
| 18:13:27 | kanzure: | er, i mean, reading |
| 18:14:17 | GnarSith: | more altcoins the merryer |
| 18:14:24 | bsm117532: | I'm leaving that position. They paid me to get my feet wet. It's not such a bad thing. There's no way this crap will ever compete with bitcoin. |
| 18:14:27 | kanzure: | yeah, i hadn't really considered the free consulting angle, but that's basically what it is :| |
| 18:14:59 | gmaxwell: | Good to hear. Network effect is a fearsome beast, for better or worse. |
| 18:15:36 | gmaxwell: | bsm117532: in any case, there is some discussion in appendix b of the sidechains whitepaper about thes sorts of luck/variance related attacks; you can also infer them from (uh looks up citation) |
| 18:15:56 | GnarSith: | we shouldnt try to discourage altcoin competition |
| 18:16:03 | bsm117532: | If anything I'm doing is worth a shit, bitcoin is going to get a PR. I made certain in my contract I can give anything I write to bitcoin. |
| 18:16:04 | GnarSith: | we need as many as we can get |
| 18:16:28 | bsm117532: | OTOH experiments need to be done, and the best place to do that is with an altcoin. |
| 18:17:05 | kanzure: | doesn't that argument completely ignore sidechains though? |
| 18:17:29 | bsm117532: | Is there a sidechain implementation yet? |
| 18:17:30 | gmaxwell: | GnarSith: I disagree very strongly, and I think the argument is intutive. Money gains its value _purely_ from network effect. Introducing competition into money makes all money less worthwhile. Additionally, the value of cryptocurrency (so far) is proped up by speculation; speculation is a much worse bet if there is a risk of many equilivent goods and you pick the wrong one. |
| 18:18:36 | kanzure: | bsm117532: even in the absence of a sidechains implementation i think there are many possible ways to experiment with bitcoin (say by using bitcoind) |
| 18:18:58 | gmaxwell: | bsm117532: expirence shows that altcoins aren't much more useful for expirementation than private test networks. You can ship an altcoin without obvious screaming vulnerablities and have it go months or years without anyone bothering to exploit it, even assuming the exploit is trivial. |
| 18:19:10 | GnarSith: | my intuition is it just gets more people involved in cryptocurrency without much negative consequence |
| 18:19:49 | bsm117532: | kanzure: How would you propose to experiment with bitcoind except by making a new blockchain? |
| 18:20:02 | helo: | it's kind of dangerous to experiment... for the experiment to be successful, there has to be significant adoption and real-world usage. but if it fails, then all of the people participating lose (possibly a lot). |
| 18:20:19 | GnarSith: | i think more people are interested in bitcoin thatn would be if doge never existed |
| 18:20:24 | gmaxwell: | GnarSith: It actually causes (quite observably) the people in the cryptocurrency space to waste their energy fighting among themselves instead of against the traditional competition. E.g. ripple going around telling banks and lawmakers that bitcoin is evil and they need to adopt ripple to head it off. |
| 18:21:41 | gmaxwell: | bsm117532: wrt sidechains, if you're just expirementing with technology you don't need a fully functional sidechains implementation. e.g. see appendix a. |
| 18:21:54 | gmaxwell: | bsm117532: making a new blockchain doesn't imply launching a new speculative asset on the world. |
| 18:22:08 | bsm117532: | gmaxwell: private test networks are all fine and well. But by making it public, distributing the code, and writing up things in a whitepaper you get peer review too. |
| 18:23:16 | bsm117532: | And yeah releasing "new speculative assets" is a shitty thing to do. But it's kind of the nature of the beast. :-/ |
| 18:23:43 | gmaxwell: | bsm117532: well you don't because for the most part altcoins don't get technical review, even when they publish stuff.. the field is flooded with tripe and review takes serious effort. My expirence has been that review is ignored or used poorly, e.g. fixed in superficial ways. |
| 18:24:16 | bsm117532: | Yep. Bad peer review is still better than no peer review. |
| 18:24:34 | gmaxwell: | What I'm saying is that you get basically no review. |
| 18:25:02 | kanzure: | you can distribute private test networks just fine. i don't know what you're talking about. |
| 18:25:52 | gmaxwell: | Because there is a flood of tripe, reviewing doesn't help, and if the things are successful (which doesn't mean well formed) they end up potentially harming cryptocurrency in general. |
| 18:25:55 | bsm117532: | gmaxwell: I'd agree with that. Too many scammy altcoins make filtering the wheat from the chaff more time consuming than it's worth. I'm hoping all that will die down thoguh. |
| 18:26:27 | bsm117532: | We need an academic-like journal for crypto-currencies. ;-) |
| 18:26:37 | kanzure: | that wont help |
| 18:26:44 | helo: | hoping for frank lloyd wright to come critique your bike shed ;) |
| 18:27:36 | gmaxwell: | doesn't seem likely to die down; plus journals are not really useful filters... no journal would have published anything on bitcoin in 2008; and plenty of journals have published papers on bitcoin since 2011 which were outright (and obviously) wrong. |
| 18:28:41 | gmaxwell: | bsm117532: altcoin stuff doesn't seem likely to die down until it's made globally clear that none of them have a future even if all the mythical unicorns and ponys they they promise are true. Even a full vision of sidechains doesn't likely get it there. |
| 18:28:54 | gmaxwell: | I'd thought coingen would have helped but it didn't seem to. |
| 18:29:26 | bsm117532: | gmaxwell: You'd have to fix the P.T. Barnum problem. |
| 18:29:33 | bsm117532: | there's a sucker born every minute. |
| 18:30:17 | helo: | publisher's clearing house problem -.- |
| 18:30:25 | tacotime: | i would doubt that there is any real impact on alts at all with the release of sidechains, because the technology will be ubiquitous. |
| 18:31:01 | gmaxwell: | yea, well coingen was supposted to point out to joe-average how trivial it is to make these things, anyone can press a button; so why should you value them? and it turns out that: (1) finding a page and hitting a button are still pretty big steps for joe average, and (2) joe happily falls for whitepaper only promises of probably unimplementable tech. |
| 18:32:27 | gmaxwell: | tacotime: on new ones? I think so. (also seems the market thinks so even on existing ones)... the whole argument is you need to invest in this new speculative thing which is nearly worthless as money, not adopted anywhere... in the hopes that it will be useful as money later because it offers something bitcoin does not. And successful pegged sidechains make that argument much harder to make, since its "if it's that worthwhile, it'll ... |
| 18:32:34 | gmaxwell: | ... become available to bitcoin users eventually via this (or some other) mechenism" |
| 18:34:05 | tacotime: | people invest based on that? i don't, i invest based on short term speculative value. and besides, anything useful created in alt space can be adapted to bitcoins later if you believe in sidechains, so i never saw the harm in alts. people claiming harm appear to believe economics is a zero sum game. |
| 18:34:54 | tacotime: | i never thought bitcoin would take over the world from day, and i still don't think it will, heh. |
| 18:37:52 | bsm117532: | I look at alt-coins like stocks. Just because dollars exist doesn't mean people won't issue stocks and bonds. There need to be legal requirements on alt-coins (just as there are on what you can call a "stock"). And we need cross-chain trading. |
| 18:38:34 | gmaxwell: | Short term speculative value makes no sense absent people (perhaps not you) that believe there is a long term value. ... otherwise, well, I've got some nice bellybutton lint to sell you-- highly limited supply! |
| 18:40:31 | bsm117532: | People were getting scammed with penny stock pump & dumps long before alt-coins came on the scene. The psychology of this is unrelated to crypto-currencies, and will continue, unfortunately. This is the SEC's role. |
| 18:41:04 | gmaxwell: | tacotime: I've seen first hand people pointing to btc/ltc as a reason to not touch cryptocurrency at all, I've seen first hand altcoin systems going out and attacking bitcoin to potential adopters and to regulatory bodies... many industries have suffered from internal compeition being much more attractive to the participants than the hard slog of going and replacing the old way of doing things. |
| 18:41:14 | tacotime: | Well, the role of the SEC is another debate. The eventual hope is you eliminate the SEC. |
| 18:41:20 | gmaxwell: | bsm117532: if that where really the control then there never would be any of this. |
| 18:42:13 | bsm117532: | tacotime: you'll never eliminate unscrupulous people getting stupid people to buy things. This is where the rule of law comes in. |
| 18:42:31 | bsm117532: | to protect the stupid. |
| 18:42:44 | gmaxwell: | so at least my _goal_ on working on the sidechains stuff is not to eliminate alts or anything likely it, it's to allow bitcoin usage to expand... but I do expect much of the alt stuff to be collateral damage along the way. |
| 18:43:00 | gmaxwell: | bsm117532: it's really wrong to characterize the victims as 'stupid'. |
| 18:43:26 | bsm117532: | I would like to make my current project a sidechain...what's the coding status of that guys? |
| 18:43:36 | gmaxwell: | Everyone reasons under uncertanty with finite time and attention available. Decision making is hard, and there are huge asymetries. The whole world can't be cryptocurrency experts or we'd starve. |
| 18:44:19 | gmaxwell: | bsm117532: depends on what your exact requirements are; e.g. does it need to be a pegged sidechain, and would the federated peg work for what you're trying to accomplish? |
| 18:45:04 | bsm117532: | gmaxwell: Well...SEC protects the consumer. I'd agree to strike "stupid". Ignorant or blinded by $$$$... |
| 18:45:33 | tacotime: | gmaxwell: I think people generally have a right to be skeptical about Bitcoin, and that competition is also to be expected. It's more a matter of how Bitcoin, etc weathers it. I think encouraging anyone to go out and make an altcoin or sidechain is the way to generally increase participation in the sector and thus, accessibility. |
| 18:45:57 | bsm117532: | gmaxwell: no idea. |
| 18:46:11 | tacotime: | For instance, I think DogeCoin overall was a very positive influence because it caused an accumulation in our general userbase. |
| 18:46:26 | bsm117532: | There's a more serious problem of convincing the founders to move away from their bad altcoin ideas. |
| 18:46:28 | maaku: | also, who doesn't love a doge mem |
| 18:47:22 | tacotime: | ...encouraging scams is a different story, but I think profitability of those is starting to approach zero. |
| 18:47:38 | gmaxwell: | tacotime: that hasn't really been my expirence yet, but it may be... of course, to that extent some infinite coin producing (as dogecoin originally was) or signer-can-issue-more-coins-for-solving-captchas 'testnet' thing could have also served that purpose. |
| 18:47:41 | bsm117532: | gmaxwell: In general, what's the (code) status of sidechains? What's implemented and where is it? |
| 18:47:45 | maaku: | also, accusations of being anti-alt are funny with jtimon and myself as co-authors |
| 18:48:03 | gmaxwell: | tacotime: yes, I agree that even absent all other things the probability in that space is approaching zero on average. |
| 18:49:20 | maaku: | bsm117532: for the federated peg -- deployable today -- there is this : https://github.com/Blockstream/contracthashtool |
| 18:49:24 | gmaxwell: | maaku: well we're not a monolith. :) (Well I'm anti-alt in genera; but don't mind interesting alts... fricoin always seemed fine to me (if doomed) because its economics were disjoint from bitcoin; namecoin mostly gets a pass because it has a usefu service; monero/friends at least deployed some new and intersting crypto) |
| 18:53:43 | bsm117532: | gmaxwell: sadly my new job is not in the bitcoin space. :-( Make me sad, this is more exciting. |
| 18:53:46 | bsm117532: | maaku: thanks! |
| 18:54:39 | gmaxwell: | bsm117532: yea, so one problem has been how the heck do you actually fund people to work in this interesting space... interesting only gets you so far. As tacotime noted, even if you don't buy my arguments that the speculative asset race is _bad_, it's not likely to continue to work. |
| 18:55:16 | tacotime: | my current job is contracting in altcoin space, so i'm rather dependent on alts existing (for now) to eat. and also may have conflicting interest, but i own more btc than anything else. |
| 18:56:02 | maaku: | gmaxwell: i think our views are aligned, although others on the team have different opinions. just more of a comment on the fact that having jorge and myself involved, and freicoin called out as an example in the paper didn't seem to quell the concern of us being crazed anti-alt-at-all-costs people |
| 18:56:58 | gmaxwell: | maaku: I think a large amount of that was from people who didn't read the paper (can't blame them, it's long... and if really their only interest is alt-speculation and not long term cryptocurrency or tech the paper would be a waste of their time) |
| 18:57:58 | bsm117532: | gmaxwell: Why would you think the speculative asset race would stop working? It's human nature driving it. |
| 18:58:51 | sipa: | bsm117532: at *some* point i hope humanity understands that there's no value in creating things without technical advantage, and hoping that it gains long term value |
| 18:59:55 | sipa: | bsm117532: speculation is fine - people speculate on the value of shares too, but that's because there's actual gambling on future divident payouts etc |
| 18:59:56 | bsm117532: | But it doesn't have to gain long term value, and I don't have to hope it does. I just have to get in early and get out before everyone else does. Entirely speculative assets with zero long term value still present a possibility to profit to speculators. |
| 19:00:07 | sipa: | if you're just speculating on the hope that some people will also speculate... |
| 19:00:10 | gmaxwell: | fool me once, shame on you, fool me 1842 times shame on me. The speculative race works because of assumptions about future value which aren't coming true, so it's increasingly hard to get people to buy in. |
| 19:00:28 | bsm117532: | sipa: exactly: speculate on other speculation -- still works. |
| 19:00:38 | gmaxwell: | people may learn slowly but they do learn. |
| 19:00:59 | justanotheruser: | bsm117532: I don't mind pump 'n dump as long as they're honest. Might as well call every new cryptocurrency pumpNdump1293 and see how it does |
| 19:01:33 | gmaxwell: | ltc was a _very_ narrow twiddling to bitcoin; more recent things have had to clame grander and grander things... (past what they can even implement, so many have moved to competing on future features now, not actualities) |
| 19:01:54 | justanotheruser: | but it is a problem when you're making an altcoin not to gamble fairly, but to trick people into giving you money |
| 19:01:55 | bsm117532: | But it's human nature to get excited over the potential for profit. People are blinded to conflicting information when that happens. |
| 19:03:56 | sipa: | and there will always be some fools |
| 19:03:57 | gmaxwell: | as bsm117532 says, full disclosure is not enough when considering the cognative defects and limited resources we all struggle with. |
| 19:04:47 | gmaxwell: | certantly its much better when everything is clear and frank. |
| 19:05:18 | bsm117532: | Even those running the scam can be blinded, and think they're not running a scam. |
| 19:05:59 | sipa: | imho it can't be a scam without someone intentionally doing it for profit |
| 19:06:12 | sipa: | like i wouldn't call litecoin a scam |
| 19:06:41 | gmaxwell: | yea, I think it's unfortunate that some people have decided to call things in this space "scam" based on effect rather than intention; thats perhaps a more useful definition of scam but its not the conventional one. |
| 19:06:44 | tacotime: | bsm117532: that's often the case with people working under people who are pumping small tech start ups and dumping the shares they purchased early on for an order of magnitude more than they were purchased for. |
| 19:07:00 | tacotime: | :) |
| 19:07:03 | bsm117532: | Which is why organizations like the SEC make rules: stocks have to have certain properties (convey ownership rights, voting rights, etc). Altcoins (and bitcoin) do not offer anything of value, only the opportunity to sell it again. So all crypto-coins are speculative scams. |
| 19:07:06 | gmaxwell: | I don't know if in english we actually have a word for something whos effect is scam-like without any judgement on the intent. |
| 19:07:35 | ericp4: | ericp4 is now known as eric |
| 19:08:09 | gmaxwell: | A lot of these things benefit from crowd-scamming, I don't mean scamming crowds, I mean the original authors could have clean hands, but expirenced actual scammers can pick it up and profit from pumping the asset (and the original creators profit long for the ride) |
| 19:08:59 | gmaxwell: | bsm117532: SEC regulation is almost totally ineffective in general. They make relatively modest civil fines in most cases. |
| 19:11:17 | bsm117532: | gmaxwell: efficacy aside...there needs to be fair exchange. Crypto-assets are just a name on a list. We've been making ledgers for thousands of years, for both good purposes and bad. |
| 19:14:14 | amiller: | has anyone here heard of "spinal codes" |
| 19:14:19 | amiller: | they're a cute use of hash chains |
| 19:14:43 | amiller: | http://nms.csail.mit.edu/spinal/ they're a really efficient form of rateless code that's useful for wireless communications |
| 19:15:11 | amiller: | (this is only on topic in the sense of wow hash chains are everywhere) |
| 19:18:00 | gmaxwell: | Yes, I'm familar with spinal coins... mostly they seemed only interesting for MIMO. |
| 19:20:16 | kanzure: | how about just "broken" instead of "scam" |
| 19:20:51 | kanzure: | e.g. all the sha256 forks are broken (because of mining vulnerability) |
| 19:21:05 | kanzure: | well, most of them. |
| 19:21:35 | bsm117532: | kanzure: just merge mine it? |
| 19:21:57 | kanzure: | right, some of them are. that's the exclusion i was thinking of. |
| 19:22:33 | gmaxwell: | kanzure: weird assumption, need to state your security model. For example most people naming a security model usually assume that hardware costs 0 (no startup costs) and is infinitely available, and the security you get is from the oppturnity cost differences. |
| 19:22:55 | gmaxwell: | and under that model existing bases of hardware are no more a threat than existing gigawatt powerplants. |
| 19:23:57 | gmaxwell: | I don't really like "broken" since ... you can imagine copying bitcoin to a forked identical system; under a conventional understanding of "broken" if this bitcoin-prime was broken bitcoin would be broken too. :) |
| 19:24:29 | bsm117532: | such an example is not broken, but it may be a scam. May not be, too. |
| 19:24:32 | kanzure: | bitcoin is entirely broken for straight forks; it reverts to the original/higher blockchain. |
| 19:24:45 | kanzure: | (which is correct, anyway) |
| 19:25:30 | gmaxwell: | "bad deal" vs "broken" |
| 19:25:53 | gmaxwell: | e.g. broken implies all the flaws are "internal", but in that straight fork example the problem is that the world doesn't want it. |
| 19:29:11 | bsm117532: | I wouldn't even say that gmaxwell, say I started a company and issued my "stock" as a "coin" (straight fork). If it's truly stock, what makes it worthwhile is voting rights and ownership of things outside the blockchain. I would not call such a thing a scam or broken or a bad deal. |
| 19:30:14 | kanzure: | er, you get really strange incentives if you allow mining that pays out in terms of your stock |
| 19:30:23 | kanzure: | i think that's just a bad idea for all sorts of interesting reasons |
| 19:31:46 | bsm117532: | It's an interesting idea for all sorts of bad reasons. ;-) |
| 19:41:24 | zooko: | :-) |
| 19:52:15 | OP_NULL: | gmaxwell: I don't think you're going to see your alt-free utopia for quite some time. there's a very popular book by a very popular bitcoin public figure being published by a very popular author which includes a whole chapter on the merits of altcoins. |
| 19:52:54 | OP_NULL: | published by a very popular.. publisher, I mean. |
| 19:54:53 | gmaxwell: | OP_NULL: I find it strange that you joined after the conversation with comments on it. |
| 19:55:15 | bsm117532: | The sidechains paper keeps referring to atomic cross-chain transfers a la Tier Nolan. Yet I'm not aware of an implementation of that. Can someone point one out? |
| 19:55:40 | OP_NULL: | gmaxwell: I don't. |
| 19:55:48 | maaku: | bsm117532: not sure there is one |
| 19:56:01 | maaku: | it's sortof bip62 dependent |
| 19:56:03 | bsm117532: | Welll !%*!@(#%*!#@! |
| 19:56:21 | sipa: | bsm117532: implement it! |
| 19:56:30 | gmaxwell: | In any case, you're talking about Antonopoulos's book, I guess? It's full of technical inaccuracies. I haven't seen that section on alts but I don't expect it to be terribly interesting, and if it was argued on the basis of the potential of new features; it seems clear to me that that argument is dead. |
| 19:56:41 | gmaxwell: | (and kinda weird that you're speaking so vaguely) |
| 19:56:41 | bsm117532: | sipa: Okay. ;-) |
| 19:57:55 | gmaxwell: | maaku: well its only bip62 dependant to be strongly secure. |
| 19:59:41 | OP_NULL: | gmaxwell: it wasn't intentional. the chapter has lots of detail about adding more functions to the hashing making the system ASIC resistant, and has some interesting comments at the end about how the future of altcoins is brighter than Bitcoin. |
| 19:59:44 | gmaxwell: | OP_NULL: people who actually develop cryptocurrency software often have a better view of whats actually possible on the technical front, and this can inform some understandings ... and sometimes not. Point is, don't be surprised when pundits in this space are taken by surprise from time to time, as they often have been. (it's no fault of theirs, it's a new area with a lot of changes) |
| 20:00:17 | gmaxwell: | OP_NULL: "adding more functions to the hashing making the system ASIC" is a long debunked line of thinking. |
| 20:00:52 | OP_NULL: | gmaxwell: of course, that's why it's funny. |
| 20:01:32 | gmaxwell: | OP_NULL: there is a summary at https://download.wpsoftware.net/bitcoin/asic-faq.pdf and the expirence with "gpu proof (not) / fpga proof (not) / asic proof (not)" scrypt supports it in practice. ahh I see what you mean, sorry. |
| 20:02:55 | gmaxwell: | in any case, I don't think of it as a utopia, people will always do things. But I doubt will be in a case where we see many more >$10 million dollar preasales of whitepaper grade speculative assets to the public; even now, and less likely in the future going on. |
| 20:03:15 | OP_NULL: | gmaxwell: I wouldn't have mentioned it at all, but the content of the chapter just juxtaposed so perfectly with your comment about altcoins earlier. |
| 20:04:40 | gmaxwell: | Fools are gonna fool, but I do really believe people learn. Some of this is just the regular learning process the pundits go through too. |
| 20:05:19 | OP_NULL: | gmaxwell: have you seen the hashcoin "whitepaper" and attempt at the same? there's hopefully enough skepticism around that it won't fly. |
| 20:05:30 | gmaxwell: | I mean, I advocated scrypt in bitcoin-dev years and years ago; and it may have even been me that gave artforz the idea; .... I know better now, but it takes time, and 99% of people involved now are quite new to bitcoin. |
| 20:06:40 | gmaxwell: | oh it's a technobabble paper. |
| 20:07:04 | gmaxwell: | "HashCoin solves this inherent flaw by introducing Transactional Immutability into the backbone of the currency. HashCoin’s Transactional Immutability places a transactional lock upon a transaction, which is immediately receipt-affirmed and then passed into the PrimeController swarm network for block confirmation." |
| 20:09:04 | OP_NULL: | isn't it fantastic? |
| 20:09:20 | kanzure: | gmaxwell: what about doing one of those comp sci technobabble paper generators for altcoins? maybe that would be more effective than coingen. |
| 20:09:31 | gmaxwell: | I wish it were on the forum so I could respond like this: https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056 |
| 20:09:32 | instagibbs: | did someone say Primecontroller Swarm Network? |
| 20:09:37 | instagibbs: | (kidding) |
| 20:10:19 | maaku: | "oedipal collision with the motherbase-prime" :P |
| 20:10:51 | phantomcircuit: | gmaxwell, i doubt hashcoin will ever exist |
| 20:11:06 | tacotime: | hey, go easy, my msc research was on motherbase-primes. |
| 20:11:10 | phantomcircuit: | 100:1 they start selling it as a "virtual" altcoin |
| 20:11:14 | phantomcircuit: | and never implement it |
| 20:12:17 | tacotime: | wait that hashcoin quote is from an actual whitepaper? willickers. |
| 20:13:02 | OP_NULL: | tacotime: I think they bought the wrong type of white paper, but yes it is from a document trying to gain interest for an impossible altcoin. https://hashcoin.com/white-paper |
| 20:13:25 | gmaxwell: | phantomcircuit: Adam was musing on perhaps there ought to exist a 'virtual altcoin market game' as a kind of distributed game / gambling thing, since people seem to enjoy playing it. E.g. you can make moves like 'create coin' which doesn't really write software, 'mine coin x' which only pays tx fees, and trade virtual coins, suffer virtual security compromises, etc. |
| 20:13:53 | gmaxwell: | OP_NULL: I can't tell if its impossible or not because it seems to not be saying anything much. :) |
| 20:14:43 | phantomcircuit: | gmaxwell, afaict it's the end of the gaw ponzi |
| 20:15:07 | OP_NULL: | gmaxwell: running a virtual altcoin exchange has a pretty high risk of it developing real value and the creator in jail. |
| 20:15:26 | instagibbs: | gmaxwell: Altcoin Story |
| 20:15:29 | instagibbs: | like Game Dev Story |
| 20:15:49 | gmaxwell: | I think my observation was that people were much happier to buy money losing hardware compared to honestly-virtual (synthetic) mining bonds which would have paid a lot more, which doesn't bode well for that. (also doesn't bode well for the argument that people are just having fun) |
| 20:16:24 | OP_NULL: | gmaxwell: there's more information scattered about their heavily whitened forum. it's going to be accepted by Target in the US on launch, it's compatible with credit card POS machines, lots of unicorn features. |
| 20:16:41 | gmaxwell: | phantomcircuit: ah, I dunno anything about gaw. |
| 20:16:42 | kanzure: | the fascination in unprofitable mining equipment seems to be much different from the general fascination in unprofitable othr things. |
| 20:16:45 | kanzure: | *other |
| 20:16:50 | maaku: | why are we discussing this here? |
| 20:17:05 | kanzure: | because irc orchestration is hard |
| 20:17:07 | sipa: | #bitcoin-psychology maybe ? |
| 20:17:08 | gmaxwell: | OP_NULL brought it up, black humor. |
| 20:17:59 | phantomcircuit: | gmaxwell, hashcoin is gawminers, they're selling them for $5 each and advertising a guaranteed resale price of $20 |
| 20:18:06 | phantomcircuit: | seems pretty obvious to me |
| 20:18:13 | kanzure: | i can't tell if sipa is being serious or not :) |
| 20:18:16 | OP_NULL: | maaku: my fault. I was commenting on the juxtaposition between what gmaxwell was saying and what was being published in books about Bitcoin. |
| 20:18:46 | sipa: | kanzure: given that the channel doesn't exist, i probably am |
| 20:18:53 | sipa: | kanzure: but i had to check :p |
| 20:19:03 | gmaxwell: | I can't differentiate many of these altcoin whitepapers from http://www.reddit.com/r/vxjunkies |
| 20:19:49 | kanzure: | so the general opinion is that the altcoin whitepaper generator wont reduce the general fascination in bad whitepapers? |
| 20:19:51 | instagibbs: | eh i dont think this is very far off-topic. but im not a mod :) |
| 20:20:00 | sipa: | gmaxwell: wth is that |
| 20:20:15 | OP_NULL: | sipa: it's about bikes, I think. not certain. |
| 20:20:27 | kanzure: | you're thinking of bike sheds |
| 20:20:48 | gmaxwell: | It's technobabble. "VX" is fictional technology that does whatever you feel like saying it does, so long as your description is completely inscrutible. |
| 20:20:58 | tacotime: | admittedly my old whitepaper was fairly bad. |
| 20:21:58 | OP_NULL: | kanzure: the point is that the number of people actually able to parse and understand a whitepaper is astonishingly low. from an outsider there's very little difference between a proper technical paper and somebody claiming to have solved a descrete log on their gameboy. |
| 20:22:50 | sipa: | i'm sure solving a discrete log for any group whose elements can be represented natively in a register of the gameboy's hardware would be very doable :) |
| 20:22:59 | tacotime: | hah. |
| 20:24:02 | gmaxwell: | some of this is the fault of us technical folks for not trying hard enough to make our communication clear. |
| 20:24:16 | gmaxwell: | Really, if you can't explain it to a layperson you don't really understand it completely... |
| 20:25:19 | kanzure: | the point is that a whitepaper is not impressive at all and that anyone can make claims |
| 20:25:27 | kanzure: | so by pressing this button you get spurious whitepapers with spurious claims |
| 20:26:05 | kanzure: | if the whitepaper itself is just to make some marketing material seem more technical, there's probably lots of ways they can do that- like copy-paste linux kernel source code |
| 20:26:14 | sipa: | haha |
| 20:26:18 | gmaxwell: | well it's not just spurious claims, a technical whitepaper is not a place where you should make claims it's where you explain how claims can be possible and give arguments for them. |
| 20:27:06 | gmaxwell: | so what these things are is not technical whitepapers, they're just marketing copy. But our technical writing is so opaque that the public can't tell, because the classify based on jargon since jargon is the most obvious feature of technical writing. |
| 20:27:10 | instagibbs: | my white paper explains how i can fleece people from offering ICOs |
| 20:27:17 | sipa: | i guess whitepapers are a medium that developed specifically to communicate in a neutral way, so it's really not intended for marketing, but for making technical claims to people with technical background |
| 20:27:38 | sipa: | ironically, that medium is now being used for marketing purposes, just to make it look more technical |
| 20:27:41 | OP_NULL: | kanzure: that's somewhat dangerous, it just makes it easier for somebody to make a bunch of technobabble to deceive people. at least now there's some level of proof of work in assembling jargon, like the hashcoin paper shows that they couldn't even do that properly. |
| 20:27:41 | tacotime: | well, my chemistry papers aren't so bad. i'm new to this field as of about 12 months ago and i lack a lot of formal education, it's bad in the sense that i have to learn anything painfully. people like me are coming from all different backgrounds and it's hard to find "elementary cryptography for morons" online. |
| 20:28:04 | tacotime: | for instance finding simple explanations of cryptographic accumulators is even kind of painful. |
| 20:28:23 | gmaxwell: | tacotime: I mean there are some nice crypto classes, but they don't cover what you need to know for bitcoin, which is an assortment of different things (and some new things as well) |
| 20:28:46 | sipa: | tacotime: "things which you can put stuff in, prove that it's in there, but not be able to find out what's in it without knowing" |
| 20:28:49 | sipa: | ? |
| 20:29:05 | gmaxwell: | tacotime: yea, e.g. there, the academic crypto writing is fairly opaque. |
| 20:29:11 | tacotime: | yeah, i understand that now, but it's hard to find it written like that. :) |
| 20:29:18 | sipa: | agree |
| 20:30:02 | kanzure: | i agree that a whitepaper generator would just make it easier to take an existing generated whitepaper and paste it up |
| 20:30:17 | gmaxwell: | yea, I don't think there is anything I've seen that actually explain something like an accumulator in simple language like that. Some authors do make an effort to explain things, most don't. Part of the problem is that publications have length limits, and ... well, lay explinations are easy to cut and won't bar your publication. They're also hard to write. |
| 20:31:05 | gmaxwell: | some of it is pretty bad, e.g. not explaining constant factors or security assumptions basically at all, except maybe via dog whistle terms that you won't notice until you've read 30 papers or so. |
| 20:31:39 | OP_NULL: | assumed knowledge is also very hard. if you over simplify you bore the upper levels of the audience, if you don't simplify enough you alienate the lower portions. |
| 20:32:02 | tacotime: | gmaxwell: which is unfortunate, because i think it makes cryptography somewhat inaccessible to the general public despite it being tremendously useful. that ars technica article on rsa and ecdsa was so, so helpful to me in understanding both of those. |
| 20:32:22 | tacotime: | satoshi had the right idea is making it readable by basically anyone. |
| 20:32:31 | tacotime: | s/is/in |
| 20:32:58 | sipa: | i was interested in cryptography since reading some article in a science magazine (you know, the dead tree format type) about diffie-hellman, near the end of the previous milennium |
| 20:33:13 | sipa: | however that word is written |
| 20:35:30 | OP_NULL: | tacotime: I think you are suffering from some bias there. the satoshi is readable, but there's a lot of assumed knowledge. I have seen in the past that others find it totally unreadable. it all depends on your background as to how much you get out of it. |
| 20:37:02 | gmaxwell: | I still think there has been no good lay description of how discrete log signatures work, conceptually, e.g. the intuition of using the homomorphism and one-wayness of the group opreations and a (non-)intreactive protocol to prove that you know a line defined by the message and private key, without revealing the private key. |
| 20:37:35 | gmaxwell: | people post lots of "HOW ECC WORKS" that goes straight into very low level operations (which they also usually explain poorly) that don't really grant any of the intution about it. |
| 20:38:04 | sipa: | i can't say that my intuition is that good either... |
| 20:38:14 | kanzure: | to be fair, most people do not trade in intuitions like this, even though they should |
| 20:38:27 | sipa: | i mean, i understand group operations and the homomorphism, but why that would imply that the discrete log is hard? |
| 20:39:04 | tacotime: | ^ that |
| 20:39:41 | sipa: | and it seems to me that nobody has a really better understanding than "well, nobody has found a way to do it efficiently!" |
| 20:40:38 | OP_NULL: | gmaxwell: yes, sadly the book that many people have purchased falls instantly into that groove and never quite manages to get out of it. there's huge descriptions of technical operations with little context to explain why they happen. as an example, describing the binary format of transactions of disk is utterly useless for anybody who isn't attempting to interface with the core client. |
| 20:41:00 | amiller: | i like that rope clock and paint mixing example of diffie hellman |
| 20:41:46 | amiller: | https://www.youtube.com/watch?v=3QnD2c4Xovk |
| 20:46:11 | OP_NULL: | amiller: I don't mind that too much, but the paint analogy is a bit broken. |
| 20:48:13 | gmaxwell: | arguing that the discrete log is hard is not something that I think can be explained easily, ... following my 'don't understand it' -- we don't, we have no proof it's actually hard. It's very easy in some groups, the hardness argument goes mostly "the tricks that work in other groups don't work in ones meeting these criteria, and we tried a lot". |
| 20:48:21 | gmaxwell: | (erp. was connection stalled) |
| 20:48:48 | sipa: | yes, i know that there is no proof |
| 20:48:58 | sipa: | but there's no intuition either to me |
| 20:49:05 | gmaxwell: | OP_NULL: thats mostly just repeating preexisting badness in our industry.. e.g. copying the bitcoin wiki, errors and all, which had a ton of low level stuff, because magicaltux was paying people to add content, and genjix was creating an alt implementation and just kinda spewed into it as he decoded the source. |
| 20:51:11 | gmaxwell: | sipa: I think generally if there is a proof its possible to have an intution, absent a proof... sometimes there is no intution at all. Well I mean, you can have an incorrect intution about discrete log hardness which will falsely tell you that it's hard in all groups, because indeed, solving it isn't just some simple closed form thing even in the groups where its not cryptographically hard. |
| 20:53:02 | OP_NULL: | gmaxwell: perhaps the bitcoin wiki needs some trap streets to catch that sort of behaviour in the future. |
| 20:54:03 | gmaxwell: | well it has a different problem now.. no one has been editing. |
| 20:54:26 | gmaxwell: | the 'developers guide' on bitcoin.org is much better. (though uh, often has really incorrect things in it, but they're fixed when people spot them) |
| 20:54:55 | sipa: | maybe we should just remove any technical information on the wiki and replace it with a link to the dev guide... |
| 21:23:43 | Luke-Jr: | sipa: that sounds like a bad idea.. |
| 21:23:58 | Luke-Jr: | just increases the barrier for contributors |
| 21:24:56 | Luke-Jr: | better to just fix the few technical inaccuracies when someone finds them |
| 21:55:54 | Taek: | I've definitely found the wiki to be helpful even after reading the whole developer's guide. Having something explained in multiple places and multiple ways is valuable. |
| 21:57:05 | gmaxwell: | Taek: the developer guide's technical content is largely elaborated and bugfixed stuff from the wiki; take care since some of the errors have not been corrected in the wiki. |
| 21:57:29 | gmaxwell: | Luke-Jr: we could also copy the devguide into the wiki and try to sync them. |
| 22:02:17 | Luke-Jr: | gmaxwell: perhaps; can we get the bitcoin.org rendered from mediawiki formatting perhaps? |
| 22:02:39 | kanzure: | i recommend not relying on mediawiki's parser |
| 22:05:49 | gmaxwell: | kanzure: there is (surprisingly good, considering how bad mediawiki markup is) support in the github toolset for rendering mediawiki wikitext. |
| 22:05:55 | gmaxwell: | but ::shrugs:: |
| 22:08:07 | Luke-Jr: | gmaxwell: bad enough that it can't handle GBT's BIPs :/ |
| 22:11:03 | gmaxwell: | not really their fault mediawiki wikitext grew organically, it's less parsable than C++ code is. |
| 22:11:54 | gmaxwell: | some of the markup has exponential complexity to parse. (e.g. the logic for handing italics vs stray astrophies in text, only made survivable by working paragraph at a time) |
| 22:14:25 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 22:14:39 | sipa: | you mean apostrophes, or atrophies? |
| 22:15:40 | gmaxwell: | bhaha apostrophes |
| 22:18:57 | gmaxwell: | In mediawiki, ''italic'' '''bold''' and '''''bold italic''''' ... now mix up some random modulation of that with words that contain 's. (e.g. possessives or french) |
| 23:25:11 | Eliel: | gmaxwell: if you want to compress the blockchain a bit, would it be possible to omit the public keys from txinputs and calculate them from the signature + transaction if needed? |
| 23:25:25 | sipa: | yes |
| 23:25:53 | sipa: | but that would mean that decompressing it becomes +- as much work as validating it (with signature checking turned on) |
| 23:26:55 | Eliel: | well, this would be for kryptoradio (bitcoin transactions broadcast on the radio waves), so I expect if someone needs the public key, they also want to verify |
| 23:27:59 | gmaxwell: | Eliel: it's quite messy to squeeze all the size out, since if you omit that data you can't compute the original tx's hash anymore. and without knowing the hash you cannot compute the pubkey (because its under the signature) |
| 23:28:34 | sipa: | gmaxwell: that's not actually true for p2sh or p2pkb |
| 23:28:49 | Eliel: | you mean, the public key is part of the data that is hashed to get the txhash? |
| 23:28:57 | sipa: | because all you need is the output being spent and the signature hash, which does not contain the pubkey itself |
| 23:29:08 | sipa: | so you can use that to recover the pubkey, and then compute the txid |
| 23:30:38 | gmaxwell: | sipa: yes though I was following too closely with Eliel's "public keys from txinputs" if its not in the input then sure. |
| 23:46:25 | ryan-c: | Eliel: I think you'd have to recover all the public keys back each coinbase or something |
| 23:46:38 | sipa: | eh? |
| 23:46:55 | ryan-c: | er, if you wanted to validate |
| 23:47:09 | gmaxwell: | ryan-c: consider a p2pkh though, you could certantly just recover the one in the signature. |
| 23:47:39 | ryan-c: | sorry, i should have spent another minute thinking before responding |
| 23:48:39 | ryan-c: | to recover the public key, you need to know what z is, which requires the previous transaction output, which would normally include a public key..... |
| 23:49:27 | ryan-c: | what's p2pkb? |
| 23:49:41 | sipa: | pay to pubkey hash |
| 23:49:46 | gmaxwell: | a normal transaction. |
| 23:49:48 | sipa: | like, normal style addresses |
| 23:49:51 | ryan-c: | oh, okay |
| 23:51:11 | ryan-c: | Eliel: are you guys looking into fountain codes for kryptoradio? |
| 23:53:13 | Eliel: | ryan-c: I'm not too deeply involved but I've been helping the to mindstorm ideas for it. This was one of them. |
| 23:54:06 | ryan-c: | Eliel: ah. I'd heard about kryptoradiou before ant thought it was cool. |
| 23:54:27 | Eliel: | I expect he'll want to have some kind of ECC there. |
| 23:54:42 | Eliel: | although, DVB-T has some kind of ECC build in too. |
| 23:54:47 | gmaxwell: | the transport carrying it has extensive error correction. |
| 23:55:27 | sipa: | error correction curves, or elliptic curve codes? :p |
| 23:55:37 | ryan-c: | error correction codes |
| 23:55:51 | ryan-c: | FEC would be a more clear acronym to use here |
| 23:55:51 | gmaxwell: | * gmaxwell laughs at sipa's joke |
| 23:55:57 | ryan-c: | (forward error correction) |
| 23:55:58 | ryan-c: | oh |
| 23:56:04 | ryan-c: | i totally missed that joke |
| 23:57:18 | Eliel: | I expect people will want to use other transports too, eventually and that's when it could be necessary to consider error correction. |
| 23:58:13 | gmaxwell: | there are plenty of reasons to use fountain codes, regardless of transports... e.g. to download blocks in parallel without any round trip delays. |
| 23:58:44 | ryan-c: | yeah |
| 23:59:11 | ryan-c: | the blockchain over radio seems like a fantastic use of fountain codes |