00:00:13 we're about to see an avalanche of alt coins - it has barely even begun 00:00:50 seems like there is a business model in double-spending tiny coins and breaking these exchanges that allow you to trade literally anything... 00:02:29 we should really release a tool to generate your own altcoin source... 00:02:47 I've been thinking about that - an alt coin wizard 00:02:49 :) 00:03:09 set the chain params, set the name/datadir, set the pow hash function - and poof 00:03:18 also, set the block reward rule and the retargetting rule 00:03:26 I think that pretty much covers it, no? 00:03:42 sipa: Ive heared that from like 10 people... 00:04:00 there was a coin that had all the generally-tweaked parameters pulled out into a config file 00:04:05 make lots of nice sliders and checkboxes so you can make your own alt that is designed to fail miserably under load 00:04:25 nsh: it's not the tweaking that needs help, half the wannabe altcoin makers can't even compile it. 00:04:35 well, aye 00:04:39 so the thing has to do all the technical stuff for you. 00:05:06 "The difficulty is already at 10 so I basically missed out on mining it already I'll probably launch another coin tomorrow" --https://bitcointalk.org/index.php?topic=380683.0 00:05:26 well, gmaxwell, the wizard could also create a virtual machine that builds it as well as a website to promote it :p 00:06:27 just monitor knowyourmeme or whatever equivalent to see the latest crazy and autotheme 00:06:31 for full generality, the hash function as well as the block reward and retargeting rules would have to be dynamically loadable 00:06:50 dynacoin 00:06:54 1nshahahaha 00:07:01 launch new module -> hardfork 00:07:21 Luke-Jr: 1ns hahahaha? 00:07:31 that's a short laugh 00:08:39 * nsh smiles 00:09:12 rather than requiring separate builds for different parameters, I prefer dynacoin :) 00:09:32 set the chain params via config file and use dynamic linking for hash pow function 00:09:37 holy shit, these exchanges take literally all the diff-1 altcoins...I'd bet a ton you could double-spend them and just break the exchange software so easily... 00:10:24 CodeShark: virtual machine?! wtf. You mean, "OP_JMP_TO_THIS_CODE" 00:10:38 we don't need separate builds for each 00:10:42 * sipa suggests OP_X86 00:10:45 hehe 00:10:50 sipa: ah yes, rootcoin 00:11:09 also, OP_SUDO 00:11:33 rootcoin can only be run as root. 00:11:42 (it's to make it more fair) 00:11:43 * petertodd really needs to release an alt-coin that scans your hard-drive for wallet.dat files and uploads them to the P2P network 00:11:55 petertodd: mines them into the blockchain, you mean 00:12:01 pretty sure its been done. 00:12:02 eeep 00:12:08 well not the blockchain part 00:12:09 sipa: kinda obvious, but why not 00:12:50 anyway, namecoin is a perfectly good datacoin given that IsStandard() is disabled... 00:16:14 there clearly are applications to decentralized data storage using some spinoff from bitcoin - but it feels like we're missing a second structure, besides the blockchain 00:16:15 yea, but you don't have to feel bad about spamming this one. 00:16:41 gmaxwell: I thought feeling bad was a pow function to limit spam 00:16:50 CodeShark: by itself some blockchain thing is not really useful for that. 00:17:38 gmaxwell: right, we need a second decentralized structure and a mechanism that compensates people for providing storage resources on the network in the coin that is generated in the block chain 00:17:53 petertodd: I mean, say you find some really _epic_ way to break namecoin with spam... you couldn't take credit for it without people being mad at you, so no sense in looking for one. This thing, otoh, I think is free target. 00:18:42 if only we had a reliable time-lock encryption mechanism :) 00:18:58 gmaxwell: true 00:19:04 CodeShark: I think you can make POW into ticking for timelock encryption. Maybe. 00:19:09 CodeShark: gmaxwell has a coin for that 00:19:40 petertodd: yeah? :) 00:19:59 actually, I should be asking gmaxwell 00:20:02 CodeShark: basically you make the pow be breaking a timelock crypto problem, devils in the details though... 00:20:21 CodeShark: the idea is just that you make the system generate random instances of a hard problem sutable for asymetric crypto, and POW is attacking those random instances. 00:20:39 Doing it with discrete log in ec groups isn't great though because rho is not progress free. 00:21:07 01:16:41 < petertodd> gmaxwell: I thought feeling bad was a pow function to limit spam -> if only it converged 00:21:15 hahah 00:21:20 lol 00:21:22 guiltcoin 00:21:28 lol 00:22:16 PoG 00:22:41 sipa: cryptographically signed court records are gonna make this one easy... 00:23:07 CodeShark: in any case, I do think that timelock crypto ticking for pow is possible, though the details may make it a bit messy. 00:23:12 sipa: one murder per block 00:23:40 sipa: gives new meaning to the term "orphan" 00:23:50 gmaxwell: do you have anything written up on the topic somewhere? 00:24:32 https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas search for timelock 00:24:39 Occupy Bitcoin http://www.ingenesist.com/general-info/occupy-bitcoin.html What if Everyone Was a Bitcoin? http://www.ingenesist.com/general-info/what-if-everyone-was-a-bitcoin.html Curiosume: The Resume Must Die http://www.ingenesist.com/general-info/curiosume-integrating-social-innovation.html http://curiosume.org 00:25:00 ah, I should check that page more often :) 00:25:29 gmaxwell: last update oct 18th? you been slackin' 00:25:39 yeah, I guess so :( 00:26:35 CodeShark: thats been there since the start. Actually the timelock idea might have been what inspired me to actually make a page for that stuff. 00:26:49 haha, ok - then I guess I never really read through it all 00:27:36 sseehh_: spammer go away (gmaxwell...stop slacking) 00:27:45 gmaxwell has kicked sseehh_ from #bitcoin-wizards 00:27:54 Wow, I didn't even see that.. was totally invisible to me. 00:31:58 you're just dropping packets with insufficient proof of intelligence 00:32:03 perfectly normal behavior 00:32:23 * nsh smiles 00:32:53 so with a timelock, we can now rent storage space by giving people an encrypted data packet along with a key they can use to claim some coins 00:33:33 yes, the devil's in the details - but in principle this should work 00:34:44 CodeShark: no, the idea is if the pow is a timelock algorithm your data is safe from pre-mature decryption on the theory that any attacker would earn more by cracking the timelock pow instead 00:35:02 CodeShark: in short, your data is safe so long as it's worth less than the total value of the timelock crypto system 00:35:06 yes, I understand that - just pointing out another application 00:35:44 CodeShark: true, I guess you could do a timelock scheme with data storage bolted on as well 00:35:57 CodeShark: hm. interesting. So I give you data, and a zero knoweldge proof that later you'll be able to decrypt the data and get coins out of it... with some large block encryption so that you can't throw away any of it. 00:36:07 gmaxwell: exactly 00:36:24 CodeShark: see, that works well with standard timelock crypto 00:36:34 I think I know how to do that without timelock crypto. 00:37:24 how? 00:37:30 CodeShark: just put funds in a multisig spendable by the timelock cracker and the enclosed key, with a nLockTime'd refund in the future 00:37:44 Take the data. Build a hashtree over it. The coins pay to the hashtree. Later, you can claim the coins if and only if you can produce a proof that looks like H(future block || data hash root) == index, and the spv proof of that index is the thing you must provide to get the coins. 00:37:58 basically the network is the interactive party in proving you still have the data. 00:39:06 gee imagine the amazing things these altcoins could do if they only bothered to think about the problem space for what.. 10 minutes? 00:40:14 gmaxwell: interesting! 00:40:45 you'd also have to prove availability, though - not just that you have it at time T 00:41:19 at least if you want random access 00:41:20 (perhaps their conception of problem space occupies a different domain [e.g. how do i become important and make money and advance my position] than ours [how can we make advances in the theory and practice of various interesting and socially-beneficial problem-sets]) 00:41:50 nsh: tl;dr: they're stupid 00:41:54 * nsh nods 00:43:29 I don't think the interesting alts out there are based on mining anyway - mining is just too insecure when you're trying to start a new alt. 00:43:55 Either your alt matters so little it hasn't been attacked, or it starts to matter and it gets killed off. 00:44:28 it should be possible to create an alt with an tapered creator mining advantage, i'd think 00:44:37 I have a slightly different view on alts - yes, the vast majority of blockchain-based alts out there are cheap imitations of bitcoin…however, I like the idea of affording some flexibility in certain coin parameters 00:44:47 that way you have a more smooth / less dangerous incubation period 00:44:48 nsh: then it's centralized 00:45:04 we might as well just do dynacoin :) 00:45:05 sure, but you can taper the centralization off algorithmically, maybe? 00:45:23 perhaps my intuition is being seasonally optimistic 00:45:27 nsh: sure, although to do it right it can't be algorithmically or you may find the schedule was wrong 00:45:35 ah, right 00:45:52 though if you define the parameters for safe coin incubation well-enough... 00:46:02 you could target the decentralization 00:46:06 (dynamically) 00:46:22 nsh: how do you measure decentralization? 00:46:33 not sure. i was wondering that recently... 00:46:34 well, you just make it that you the creator get to sign statements allowing more decentralization as a one-way rachet 00:46:43 ah, yeah 00:47:06 so a certain (set of) key(s) has a mining advantage, that can only decrease with some broadcast signal 00:47:19 nsh: yup 00:47:19 mmm, dunno, sensing implementation difficulties the more i think about it 00:47:23 CodeShark: well you could do something like prove you have it at _every_ block, and then to later spend the coin produce a snark that compresses all the proofs. 00:47:53 hm. well I suppose thats not quite right, since you could have only had it at the end. 00:47:58 Well in any case, it's better than doing nothing. 00:48:02 gmaxwell: right, that's the problem 00:48:06 nsh: you could lower the difficulty by the percentage of proof-of-stake signatures a block has 00:48:11 nsh: nah, no difficulties there: the signature is a substitute for PoW. you being the creator you'll use it responsibly; obviously you can play games and destroy things with that power too 00:48:26 then an itsy bitsy premine gives you an advantage that slowly tapers off 00:48:30 gmaxwell: to prove availability at a particular time, wouldn't you need to provide a challenge at that time? 00:48:49 CodeShark: though flexibility in researching optimal parameters is cool, a) there are more interesting things to research, but, more importantly, b) by just forking Bitcoin and creating an alt, you decrease the value of the digital scarcity that defines Bitcoin 00:48:52 's value 00:49:11 hmm 00:49:15 meh 00:49:26 i don't care 00:49:33 BlueMatt: whether or not it decreases Bitcoin's value, it is an inevitable phenomenon - therefore, if Bitcoin cannot withstand it, we have a serious problem 00:50:13 I find that argument ridiculous: "its inevitable, so we shouldn't try to prevent it and should instead fully support it!" 00:50:16 makes no sense to me 00:50:26 BlueMatt: I don't this is zero-sum. Stupid people throwing stupid money at alts aren't necessarily going to speculate on bitcoin instead 00:50:28 the exact same features that make Bitcoin so difficult to stop applies to any of these alts 00:50:31 support? 00:50:31 BlueMatt, i'm not sure i follow how more (of any kind of) cryptocurrency decreases the scarcity... isn't the scarcity defined relative to the utilization of mining resources? 00:50:32 BlueMatt: well, here's an interesting thought question: if I create BTCv2 that is just transactions embedded in BTCv1 with a fancy new scripting system, what happens? BTCv2 transactions still need to pay fees in BTCv1, and I can design my scheme that both are 1:1 convertible (by allowing v1 to be destroyed to create v2) 00:50:55 maaku: oh, I'm not saying its zero-sum, I'm saying that its not independent, and far closer to zero-sum than independent 00:51:04 so if more people mine alts that wouldn't be mining btc, then you've dilution, but if that mining power is not diverted but added... 00:51:28 petertodd: fuck mastercoin ;) 00:51:48 nsh: no, its defined as relative to the number of people interested in cryptocurrencies 00:51:50 BlueMatt: hehe, I have a lot of incentive to make such a thing work... 00:51:58 petertodd: ?? 00:52:25 nsh: mining isnt the important part to me, but it is as well 00:52:31 sipa: petertodd works for mastercoin..... 00:52:35 heh? 00:52:35 sipa: I am mastercoin's chief scientist now... 00:52:39 wtf? 00:52:55 BlueMatt, hmmm. question is then how the elasticity of coin interest responds to the proliferation of alts 00:53:02 * Luke-Jr notes MasterCoin was offering a very low salary :P 00:53:04 i suspect it's pretty nonlinear 00:53:05 sipa: I had decided I was going to quit the day job, and then by good luck they offered me a job at the same time 00:53:32 Luke-Jr: meh, salary isn't everything 00:53:46 petertodd: in any case, if a coin is 1:1 trade-able for bitcoin, and mined on its own chain (I agree currently merged-mined isnt very good, but I think we should work on making that more accessible instead of saying lets put shit on the chain) I fully support it as awesome fucking research 00:54:01 nsh: I disagree very highly 00:54:23 then you're probably right :) 00:54:27 BlueMatt: well, what's interesting is how much data do you actually need in the chain? data-hiding is a serious issue, but maybe you can make the incentives to not hide data and/or recover from lost/hidden data. (see zookeyv) 00:54:39 petertodd: it isn't, but does Mastercoin really offer anything more? :P 00:54:43 nsh: heh, I'm by no means a wizard, even if I do hang out here :p 00:54:44 BlueMatt: if everyone played nice timestamping would just be enough 00:54:51 * nsh smiles 00:55:00 if everyone played nice we wouldn't need currencies :p 00:55:20 CodeShark: I suppose that it just reduces to the storage throughput stuff on the altcoin page as one way of showing you have it at all times. 00:55:22 CodeShark: not sure I agree 00:55:26 Luke-Jr: well, for me it's about the pay-per-hour-of-studying-cryptocurrencies, and mastercoin's offering full-time crypto-coin studying :) 00:55:30 e.g. instead of paying you just make storage a byproduct of mining. 00:55:43 petertodd: is that really all they expect of you? 00:55:46 Luke-Jr: or at least, we wouldn't need currencies that are deliberately scarce 00:56:05 Luke-Jr: mastercoin is roughly speaking a blank slate, so roughly speaking yes 00:56:10 BlueMatt: "merged mining isn't very good" -- because of the security risk of diluting the reward function? 00:56:11 petertodd: well, instead of working on fun cryptocurrencies problems like scaling, you've ended up working on how to best hide data in coins not designed for it... 00:56:16 instead of designing for it 00:56:32 BlueMatt: yes, but once you accept that as your model... then obviously you should work on scaling 00:57:29 maaku: because if you make a new researchcoin today, getting it merged-mined by enough mining power isnt a trivial problem, mostly 00:57:40 BlueMatt: see, if mastercoin is merge-mined, there's no reason to work on making bitcoin scale better, but if mastercoin isn't merge-mined and is embedded in the blockchain, then there's every reason to make bitcoin scale better 00:57:49 scaling is a solved problem. we just all have to trust random people we've never spoken to in strange countries with unknown interests. cf. BGP 00:58:00 , GRX, &c. 00:58:39 I do not agree with the notion that the bitcoin protocol is a general low-level protocol - if we really want to build a network like that, we should design a low-level blockchain-based protocol (for, say, timestamping) 00:58:53 without attaching anything else to it 00:59:01 it should be completely agnostic as to the contents of data packets 00:59:44 CodeShark: I suspect we're going to end up with that, and specifically, the magic word is "proof-of-publication" 01:00:34 CodeShark: and that's a problem? 01:00:42 furthermore, proof-of-publication doesn't require all the data contents to be stored on the blockchain itself 01:00:49 petertodd: my view: ignore all non-btc-denominated cryptocurrencies: they all need to die and should be treated as shit anyway. after you do that, you have to somehow make the total throughput of btc-denominated transactions scale, that can come in the form of alts that are on their own btc-denominated chain or however you want, the whole system has to scale 01:00:52 hashes would be sufficient 01:01:20 we could completely separate the data storage/query mechanisms from the timestamping mechanism 01:01:23 CodeShark: no it does: if it's not in the blockchain there's no proof anything was in fact published. that siad, the existing bitcoin system is kinda weak on that respect... 01:01:52 petertodd, there are different (but overlapping) use-case sets for proof-of-existence and proof-of-publication 01:02:00 CodeShark: the ideal might be some pow function that forces you to prove you have access to some data set, but that's not what we have 01:02:09 petertodd: if it were easier to get mastercoin merged-mined (eg to the scale of namecoin), and you can do 1:1 exchange to a secondary chain, do you not agree mastercoin /should/ be on a separate chain at that point? 01:02:18 ok, yes, I get the distinction now between proof-of-existence and proof-of-publication 01:02:21 also publication might have gradations, as not everything is published to * 01:02:43 BlueMatt: if you can wave a magic wand and get it to reasonable hashing power, lovely, but there is no such magic wand so I can't advise them to do that 01:02:57 BlueMatt: more likely I'd get there by designing a good merge-mined proof-of-publication scheme 01:03:17 ok, so our disagreement is how hard it is to get merged-mined a new coin 01:03:48 besides the fact that mastercoin represents extra blockchain bloat, I'm also concerned about the unpredictable nature of block intervals…and the average length of that interval 01:04:02 BlueMatt: pretty much, and there's lots of ways forward: IE if I managed to find a way to make bitcoin tiself scale in some unspecified way, then mastercoin dumping data on the blockchain wouldn't matter 01:04:22 10 minutes on average doesn't seem like sufficient granularity for a lot of things 01:04:41 petertodd: better != infinitely 01:04:44 CodeShark: given the selfish mining stuff I think we're going to find that 10 minutes was optimistic... 01:05:25 sipa: my suspicion is there is a fundemental security and scalability tradeoff with proof-of-publication, so you'll wind up with some scheme that lets you make choices about that tradeoff - pay more for more secure coins 01:05:51 sipa: txout storage fees based on value are nice there, but they change economics... 01:05:59 very much so 01:06:37 shouldn't the storage fee be based on size, not value? 01:07:05 CodeShark: NO, based on value because more value needs more security needs wider spread holders who actually have the data 01:07:23 ah, ok 01:07:52 if we used a base-1 encoding, we could make size and value be the same 01:07:55 am i a wizard yet? 01:07:59 CodeShark: e.g. Suppose I want to destroy all (public) copies of some blockchain data, in the Bitcoin system that's going to be extremely hard, roughly a 51% attack, but if bitcoin mining was sharded such that you could mine with 1/8th of the blockchain data, you'd wind up with a system where you may be able to do a 51% * 1/8th attack instead 01:08:22 * petertodd gives andytoshi a robe and pointy hat 01:08:27 why not put mastercoin on namecoin? 01:08:31 or hey, devcoin or ixcoin 01:08:31 right, I get it now, petertodd 01:08:58 maaku: why bother? it's not mastercoin's problem that it crowds out other uses of the blockchain 01:09:26 the fundamental problem here, IMO, is the misplaced incentives 01:09:38 CodeShark: agreed 01:09:43 there are no rewards in the bitcoin network for providing storage nor for relay 01:09:45 petertodd: just pointing out that there are other merged mine chains with high hash rates 01:09:53 CodeShark: especially with regard to the UTXO set... 01:09:59 i actually think that it is perfectly fine to put whatever you want on the block chain 01:10:13 petertodd: well, I find the difficulty of getting a real research coin merged-mined to be a problem that needs solving, so I'd argue that you (as someone paid to work on this) should work on fixing that problem instead of working on hiding shit in the chain so that people cant block it 01:10:18 and if anyone has a problem with that ... it's your own damn fault for not coming up with and implementing a better fee system 01:11:31 BlueMatt: meh, I think I've basically solved the "hide shit in the blockchain" problem very thoroughly, something we need *someone* to have done if only to understand the risks 01:11:33 without fees going to those providing the storage that is wasted, the incentives can't align 01:11:57 BlueMatt: note I also have a half-decent solution to UTXO bloat, so it's not like it's the only thing I've been working on 01:12:23 sipa: and fees can't go to those providing the storage because ... ? 01:12:33 i think there is always an incentive for people to put stuff on the blockchain, it's not their problem ... so it's up to bitcoin to figure out pruning strategies 01:12:34 not saying it's easy, but also no one's shown it impossible 01:12:38 petertodd: I'd love to see some of those implemented :) 01:12:47 maaku: well, i wouldn't call it bitcoin anymore in any case 01:12:58 maaku: modulo utxo bloat, the existing fee system works just fine: really we've got people whining that they aren't getting cheap transactions because something else can afford a higher fee/byte 01:13:46 CodeShark: heh, well actually I've got an unreleased upload-files-to-the-blockchain tool that makes them into a shared consensus namespace... add timelock crypto to it and you'd have a rather frightening system 01:14:12 CodeShark: fortunately $0.1/KB is kinda pricey, and it's even higher if you want to hide in normal-looking transactions 01:14:31 sipa has left #bitcoin-wizards 01:15:11 petertodd: I also wrote a tool once to upload arbitrary text (base58 encoded) to the blockchain :) 01:15:43 I'm only guilty of using it a few times :) 01:15:53 there is a rickroll somewhere in testnet (i have the command to play it, but not on me right now) 01:15:55 CodeShark: heh, it's not rocket surgery... although I think the trick is the retrieval side of things so people find it useful - hence my shared consensus namespace thing 01:15:56 i think one of you guys did that 01:16:05 * petertodd looks guilty 01:16:24 i thought it was petertodd, didn't want to accuse since i wasn't sure :P 01:16:36 lol 01:18:34 j'accuse! 01:18:41 (best chess move) 01:19:03 andytoshi: heh 01:19:27 andytoshi: everytime someone claims bitcoin scales I edge a little closer to releasing the upload tool :P 01:19:34 haha 01:19:51 petertodd: someone uploaded the source code for a python tool to upload arbitrary data 01:19:56 it's still somewhere in the block chain 01:20:17 CodeShark: yeah, they fucked that one up though because strings blk*.dat wasn't cut-n-paste-able 01:20:30 CodeShark: cute though 01:21:22 the retrieval tool shouldn't rely on the blk*.dat files at all 01:21:30 retrieval should be possible via p2p protocol 01:21:46 petertodd: see, you don't need an upload tool.. you just need datacoin. 01:21:47 CodeShark: no, I just mean that bootstrapping it was tough because you had to decode the tx containing the tool yourself 01:22:02 it has the tool built in. 01:22:17 CodeShark: well that's a fun one: you can easily design this stuff to be SPV compatible re: bloom filters 01:22:58 CodeShark: even easier if someone implements prefix filters 01:23:03 right 01:26:28 gmaxwell: it's always a trade-off between fees and security of your data... 01:27:31 well, wrt txout bloat, the most sensible "wizards" solution seems to be to decrement the output value as a function of age until it drops to zero, at which point it is unspendable 01:28:21 CodeShark: MMR TXO commitments shift storage to wallets (roughly speaking) 01:28:55 MMR - not sure I'm familiar with that acronym 01:29:08 CodeShark: merkle-mountain-range 01:29:33 how does that work? 01:30:16 CodeShark: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194 01:31:51 CodeShark: there's some ugly issues re: bandwidth storage tradeoffs however - given that miners don't actually have an incentive to broadcast their blocks to >%30 of hashing power there can be incentives to make blocks full of UTXO spends that are ancient that no-one has cached 01:32:06 CodeShark: but that's a general problem... 01:34:01 ah yes, interesting stuff. it's too bad the forums are so cluttered with garbage…on occasion you do find good reads. I suppose I could filter by author :) 01:34:17 CodeShark: heh, well my fault for not having it writtne up as a paper yet 01:43:03 the way things are right now, a secure signing node would have to store the complete transactions containing their outputs anyhow 01:43:55 if for no other reason than that there's no other way for it to verify the output values 01:44:33 so here we're also adding an O(log2) structure for proofs 01:44:43 of existence in blocks 01:50:05 existence of new outputs/removal of spent outputs, I should say 01:50:46 yeah, it's a fair bit of bandwidth over just the txin data 01:51:06 OTOH it is purely a tradeoff - if you have the UTXO set you don't have that cost 01:54:24 so you would advertise whether or not you have the UTXO in the initial handshake? 01:55:11 hmmm, there might be privacy implications in the negotiation 01:55:19 well, e.g. for a block being distributed if you don't have the utxo ask your peer to provide the proof 01:55:54 asking the peer to provide the proof requires one more roundtrip…which introduces greater latency 01:56:15 CodeShark: yup, which is why you want to have as many utxo's on hand as you can store 01:56:40 point is you could establish whether or not you have the complete utxo in the initial negotiation 01:56:42 CodeShark: but at some point you run out of space, so you drop ones that are unlikely to be spent 01:56:58 CodeShark: well you could give your peer a bloom filter of wha tyou have, for example 01:57:08 right, something along those lines might work 01:57:29 yup, lots of options, main thing is that all those options are things that aren't forks 01:59:39 perhaps it might be good to enable an ecology to these things: let various different approaches be 'right' and let natural selection on the basis of effectiveness and cost tend toward improvement 02:00:36 the monocultural aspects of the bitcoin network should be whittled to a fine point of essential security and consistency 02:00:56 problem is natural selection favors diversity (i.e. forks) 02:00:59 nsh: agreed, although people tend to complain that their wallets don't go fast :) 02:01:15 mmm 02:01:20 well, these approaches don't require block chain forks - but they do require care with protocol issues 02:02:49 CodeShark, can't you look at the (hard)fork border as the boundary of an island (let's call it Coinagascar)? you can still have diversity within those confines... 02:03:30 I suppose we could separate the core validation algorithms from the specifics of the protocol itself :) 02:03:46 as in the specifics of networking with pees 02:03:48 *peers 02:03:50 * nsh nods 02:04:17 the downside is that you lose some of the shepherding function of the core dev team 02:04:44 but i would anticipate that function isn't long-term sustainable if bitcoin grows into a very large ecosystem anyway 02:05:33 and it's already accepted that you choosing to use one solution over another can have financial implications 02:05:41 s/you // 02:18:56 "In conclusion, I think that humanity should stop publishing papers about Byzantine fault tolerance. I do not blame my fellow researchers for trying to publish in this area, in the same limited sense that I do not blame crackheads for wanting to acquire and then consume cocaine." 02:19:15 ah, microsoft research, how i love thee 02:19:21 * nsh smiles 02:21:56 hah, that whole piece is great 02:21:58 ( https://research.microsoft.com/en-us/people/mickens/thesaddestmoment.pdf ) 02:25:41 it's generally true of Byzantine fault tolerance. People who shit on Bitcoin are either in denial or unaware of the complete failure that field has been. 02:26:18 An endless series of impossibly complicated protocols which can only work under highly unrealistic constraints and which generally burst into flames on contact with reality. 02:32:51 it's basically a field that people have been wanking on more or less ineffectually since the late 1970s, making little useful progress, and then Bitcoin comes along and delivers a working system that is secure in the anonymous model, where like everything else required previously agreed participants, requires linear communication (as opposed to quadratic in the number of participants), and is relatively simply explained vs the charts ... 02:32:57 ... in that paper. ... and did so basically as a footnote on the way to producing an entirely new kind of currency. 02:44:15 reminds me of... atomic chemistry until the 1870s. decades of top scientists debating fancy models, vortex theories, all sorts of complex contrivances, and then Mendeleev comes along with the periodic table, pow! 02:49:39 gmaxwell: OTOH PoW blockchains appear to only work in conjunction with financial incentives 02:50:14 petertodd: indeed, bitcoin is _not_ a fully general solution. 02:51:13 gmaxwell: though in many cases you can limit your "byzantine fault vulnerability" to a small part of software that is trusted to give an honest signature for some type of "fake work" 02:51:15 it just happens to work (so far) for like ... the only application known where byzantine fault tolerance was actually a hard requirement. :P 02:51:21 gmaxwell: lol, there is that! 03:06:17 serendipity 04:20:16 Fistful_of_Coins is now known as BitShifter 04:21:01 BitShifter is now known as Fistful_of_Bitco 04:21:11 Fistful_of_Bitco is now known as Fistful_of_Coins 13:16:32 uiop has left #bitcoin-wizards 19:47:45 nsh- is now known as nsh