02:29:06 | rabbit2: | sipa here? |
02:29:42 | rabbit2: | we were discussing shifting the 51% attack from need all of current hashing power |
02:29:52 | rabbit2: | to all hashing power ever used in the history of the network |
02:30:20 | rabbit2: | anyone feel like shooting my idea on this down? |
02:32:35 | rabbit2: | I had conceded there was a nothing-at-stake problem with the idea. |
02:32:40 | rabbit2: | This is not correct. |
02:32:51 | rabbit2: | There is no nothing-at-stake problem. |
02:33:11 | rabbit2: | Any nothing-at-stake fanatic want to take this on? |
02:33:36 | rabbit2: | no then? |
02:33:47 | rabbit2: | okay, I'll try again another time. |
02:37:07 | kanzure: | uh? |
02:37:18 | rabbit2: | uh |
02:37:39 | rabbit2: | are you requesting an explanation? |
02:37:58 | kanzure: | no, i think you are being silly |
02:38:03 | kanzure: | why would you assume that your network agrees about history? |
02:38:04 | kanzure: | that's the whole problem |
02:38:52 | rabbit2: | the network just has to agree about the amount of total work performed throughout history |
02:38:59 | rabbit2: | this is verifiable |
02:39:42 | rabbit2: | of course you don't observe work directly, but you can measure it based on all historical hash submissions |
02:39:54 | rabbit2: | I submit work in the form of a txn |
02:39:59 | kanzure: | the absence of evidence is not the evidence of absence |
02:40:16 | rabbit2: | why don't we discuss specifics instead of platitudes? |
02:40:34 | rabbit2: | I submit work in the form of a txn below the current difficulty level |
02:41:04 | rabbit2: | In this txn I submit a novel public key associated with this work |
02:41:41 | rabbit2: | This public key owns a unit of historical work for the indefinite future |
02:41:43 | Luke-Jr: | [02:38:52] the network just has to agree about the amount of total work performed throughout history <-- this is ALREADY the case |
02:41:52 | rabbit2: | I know |
02:42:10 | rabbit2: | The point is that you can turn historical work into a commodity |
02:42:14 | Luke-Jr: | … |
02:42:38 | rabbit2: | Mining power does not need to be based on work currently performed as is presently the case |
02:42:48 | rabbit2: | It could be based on all work performed throughout history |
02:42:59 | kanzure: | yeah you could include a hash of previous work or something |
02:43:09 | rabbit2: | So, I have this public key that is associated with the previous work I did |
02:43:44 | rabbit2: | In each block, we draw a unit of historical work and select this unit of work as a block minter |
02:43:58 | rabbit2: | The public key associated with the historical work signs the block. |
02:44:19 | rabbit2: | You cannot transfer ownership of historical work on the chain. |
02:44:37 | rabbit2: | So we can assume that the guy who did the work originally also controls the public key right now. |
02:44:55 | rabbit2: | Someone could attempt to sign two competing chains with the same historical work |
02:45:22 | rabbit2: | However, this is observable. If we see two contradictory chains signed with the same historical work, we can identify the offender |
02:45:38 | rabbit2: | and include proof that he has signed two historical forks in the blockchain |
02:46:09 | rabbit2: | based on this proof, the chain can confiscate his historical work, removing him from the lottery |
02:46:26 | rabbit2: | he would lose a perpetual stream of txn fees due to his bad behavior |
02:46:28 | kanzure: | lots of people have had that idea, are you aware of why they were broken |
02:46:52 | rabbit2: | no, I don't think so. But why don't you explain why it is broken? |
02:46:52 | kanzure: | (have you studied why they were broken) |
02:47:00 | kanzure: | because my time is valuable and i am bored by you? |
02:47:10 | rabbit2: | yes, I have studied a lot of this stuff |
02:47:16 | kanzure: | i am simply informing you that you have a ready source of material to work from |
02:47:22 | rabbit2: | and contributed to papers on it |
02:47:50 | rabbit2: | could you explain why it is broken, please? |
02:48:02 | kanzure: | i just said no, why are you asking so soon |
02:48:05 | kanzure: | *asking again |
02:48:07 | rabbit2: | there is no nothing-at-stake problem here |
02:48:17 | rabbit2: | ... |
02:48:25 | rabbit2: | Wow |
02:49:12 | kanzure: | i would start by grepping https://download.wpsoftware.net/bitcoin/wizards/ |
02:49:29 | rabbit2: | I have been over a lot of that quite thoroughly |
02:49:34 | rabbit2: | ... |
02:50:01 | rabbit2: | Could you please be specific? Instead of saying, somewhere in 10000 pages of text is an explanation of why you are wrong. |
02:50:36 | rabbit2: | Do you understand the nothing-at-stake problem? |
02:50:51 | rabbit2: | Because I don't think you do. |
02:51:09 | kanzure: | based on what evidence? |
02:51:39 | rabbit2: | I am assuming that you think what I am suggesting couldn't work due to the nothing-at-stake problem |
02:51:42 | rabbit2: | is this correct? |
02:52:01 | rabbit2: | Or is there some other problem you are referring to? |
02:52:17 | rabbit2: | in your exceptionally vague reference to 10000 pages of text |
02:52:18 | kanzure: | okay, so based on no evidence |
02:52:37 | rabbit2: | can you simply answer, yes or no? |
02:53:06 | rabbit2: | Or are you going to continue to say "I won't tell you what I think is wrong with your idea" even in the vaguest possible terms |
02:53:14 | rabbit2: | however, I will continue to maintain that it is wrong |
02:53:38 | kanzure: | do you genuinely think that there are no alternative interpretations of my messages? i fully intend you to interpret my messages literally. |
02:53:40 | roidster: | roidster is now known as Guest62329 |
02:53:48 | rabbit2: | Enough |
02:54:46 | kanzure: | i haven't even made a statement about whether or not i think your idea is bad, and you have gone off into an extremely weird conversation based on zero evidence |
02:56:43 | rabbit2: | you said, "lots of people have had that idea" |
02:56:55 | rabbit2: | "are you aware why that idea is broken" |
02:57:10 | rabbit2: | I asked for a reference to support "lots of people have had that idea" |
02:57:15 | rabbit2: | to start out with |
02:57:24 | rabbit2: | even a name would be helpful here |
02:57:54 | rabbit2: | without a name or any other specifics, I have to guess at what you might mean |
02:59:20 | rabbit2: | anyways "are you aware why that idea is broken" seems to indicate a "statement about whether or not I think your idea is bad" |
02:59:35 | rabbit2: | if it doesn't and I misunderstood you then I apologize |
03:03:49 | rabbit2: | rabbit2 has left #bitcoin-wizards |
03:11:28 | kanzure: | well you can choose to believe either that i am maliciously throwing you on a wild goose chase or that i genuinely believe that if you look in the logs that you will find previous proposals very similar to your "just know all competing histories" idea. |
03:11:51 | kanzure: | (and attacks against same) |
03:12:58 | rabbit2: | the attacks assume that it is possible to transfer ownership in the past |
03:13:21 | rabbit2: | if it is not possible to transfer ownership on the chain, the attacks do not work anymore |
03:13:24 | kanzure: | hmm, so i grepped the logs a bit and the oke0_ person seems to have your same idea |
03:13:36 | kanzure: | go read the replies to his statements in the logs |
03:13:37 | rabbit2: | thanks I will check it out |
03:13:48 | kanzure: | (now why couldn't you have done that on your own? sigh) |
03:16:34 | rabbit2: | could you provide a link |
03:16:41 | kanzure: | no |
03:16:51 | kanzure: | just https://download.wpsoftware.net/bitcoin/wizards/ |
03:17:27 | kanzure: | nsh asked for a pointer from the logbot, you're in luck http://download.wpsoftware.net/bitcoin/wizards/2014-05-29.txt |
03:18:38 | tromp_: | .txt -> .html |
03:25:21 | kanzure: | another one was the zack-truthcoin person |
03:25:29 | kanzure: | "< zack-truthcoin> if they are caught signing onto competing forks, then they lose all money." |
03:25:35 | kanzure: | just keeps happening again and again |
03:25:42 | kanzure: | it's almost criminal to have no context at this point |
03:26:49 | fenn: | when they outlaw having no context, only criminals will be context-free |
03:27:39 | kanzure: | except context is freely available and hugely useful |
03:27:58 | kanzure: | if you are trying to design an alternative system of byzantine agreement it would be a good idea to check the -wizards logs |
03:28:53 | rabbit2: | yes oke_ does have the exact same idea, (except that he wants to use some form of inflation) |
03:29:24 | rabbit2: | to compare historical work to current work, I believe that could create problems |
03:29:48 | rabbit2: | I don't see any critical objection raised to the idea in that thread |
03:29:55 | kanzure: | keep reading |
03:30:00 | kanzure: | there were many objections |
03:30:00 | rabbit2: | But you are completely right that the idea has been proposed before |
03:30:06 | rabbit2: | I read the entire thread |
03:30:11 | rabbit2: | _oke addressed them all |
03:30:31 | kanzure: | well try the truthcoin person next, ugh |
03:30:35 | rabbit2: | He is right that you can't sell information |
03:30:39 | kanzure: | this should be your job, not mine |
03:30:41 | rabbit2: | that you can stil use |
03:30:47 | rabbit2: | truthcoin person is whom? |
03:30:57 | rabbit2: | you are making my job much easier thank you |
03:30:58 | kanzure: | his name has "truthcoin" in it, just grep for that |
03:31:42 | kanzure: | or grep for "caught" in the logs |
03:31:57 | kanzure: | haha: |
03:31:58 | kanzure: | 15:34 < gmaxwell> mr_burdell: but the absense of time travel can prevent that. |
03:32:20 | rusty: | rusty has left #bitcoin-wizards |
03:32:47 | kanzure: | also make sure you read the part that goes like "15:36 < gmaxwell> zack-truthcoin: In the situation I setup Alice allows her coins to...." |
03:34:09 | gmaxwell: | perhaps the POS document needs some additional elaboration on this particular 'improvement'. I think it was andytoshi's hope that the document gave a general enough argument that people would stop getting snowed by "improvements" that didn't fix the fundimentals, but this one still seems to be popular. |
03:34:33 | kanzure: | what i hate most is remembering any of it |
03:35:10 | kanzure: | it's like a mental index of irc trolls or something. totally wasted space. |
03:35:58 | gmaxwell: | kanzure: have you ever read neal stephenson's anathem? ... in the book the society of scholars has a punishment system which involves having to memorize from a book of subtly wrong proofs. ... sometimes dealing with the altcoin stuff feels like that. |
03:36:01 | rabbit2: | 15:36 doesn't apply to coke_0's idea because there is no expiration |
03:36:43 | rabbit2: | the idea differs because the stake can expire |
03:37:10 | rabbit2: | inflation is also a problem with coke_0's idea (depending on what he means by this) because it is also a form of expiration |
03:37:38 | rabbit2: | you would not want to inflate at all, so that all historical work is equivalent regardless of when it was performed |
03:37:39 | gmaxwell: | rabbit2: the perpetual bonds things have been proposed several times before, they suffer many problems. For one, they still really do expire, e.g. when you've used them long enough to get their initial value back, then they're economically expired. (if they _never_ do, then you have an incentives problem). It also seems deeply impossible to prevent transferability in the face of rules-adversarial users. |
03:38:32 | rabbit2: | you can't prevent transferability through rules, but users have an economic incentive not to perform transfers |
03:39:03 | rabbit2: | they're economically expired only after the work contained in them is so small that it is negligible |
03:39:20 | gmaxwell: | For example, here is how you make a non-transferable key transferable: Instead of generating the key myself, I ask a smart card to do it. Then I transfer the smartcard to you. While maybe I tampered with the smartcard's security, it's likely good enough and it retains most of its value. |
03:40:06 | gmaxwell: | rabbit2: there is no "work contained", because the history can be rewritten to the point where they have full work. This is the essance of a nothing at stake attack. Please don't jump ahead without understanding the argument. |
03:40:52 | rabbit2: | I'm assuming the smartcard doesn't exist. |
03:41:15 | gmaxwell: | they already do exist. |
03:41:38 | kanzure: | maybe the term "nothing-at-stake" doesn't sound cool enough to be considered or something |
03:42:25 | rabbit2: | I don't understand what you mean by this "rabbit2: there is no "work contained", because the history can be rewritten to the point where they have full work. This is the essance of a nothing at stake attack. Please don't jump ahead without understanding the argument. " |
03:43:04 | gmaxwell: | and if you would prefer a transferability solution without tamper resistand hardware. ... it can work purely in softward, e.g. for any elgammel-group signature system, I ask three non-cooperating parties to generate pubkeys A,B,C and I compute a composite pubkey Q = A+B+C+D (d is my pubkey). Q is the key I register in the system, and A+B+C help me sign. later I can ask a,b,c to transfer their signing helping to another party. Now ... |
03:43:10 | gmaxwell: | ... I can't cheat them on the trasfer without the collusion of A+B+C. |
03:43:40 | rabbit2: | Yes, but I could collude with them... |
03:43:46 | gmaxwell: | rabbit2: Yes, it's clear that you don't. Have you read pos.pdf? |
03:44:10 | rabbit2: | The value of the expected value of the key after transfer will always be < the expected value of the key before transfer |
03:44:32 | rabbit2: | so there are never economic incentives for transfer |
03:44:54 | rabbit2: | if you do transfer a key, you would want to do so in a legal environment where you can go after people in meatspace |
03:45:01 | gmaxwell: | rabbit2: sure, and? in bitcoin people are perfectly happy to trust their mining to mining pools who can secretly rob them. In practice for some threshold the key generators will be quite secure, and they make your bond much more valuable because they make it mostly tradable. |
03:45:30 | gmaxwell: | rabbit2: how are they going to go after anyone? ... so you're now assuming that all participants in the system have some kind of identity? attested to by whom? |
03:45:50 | rabbit2: | all participants don't have to have some kind of identity |
03:46:05 | rabbit2: | however if you are going to go around transferring keys, then you would only want to do so among |
03:46:06 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
03:46:16 | rabbit2: | the set of participants that has strong identity in meatspace |
03:46:29 | gmaxwell: | rabbit2: the transfer is preferable in some cases because of a time preference for money, money years from now is worth less than money today to many people much of the time. |
03:46:37 | rabbit2: | you would obtain a higher price in this setting because you could go after people for cheating |
03:46:39 | gmaxwell: | (ever heard of a loan? people pay some pretty remarkable interest...) |
03:47:10 | rabbit2: | I have to go, but thanks for the discussion. |
03:47:17 | gmaxwell: | But this tangent is irrelevant until you've even understood the _MOST BASIC_ problems with pos. |
03:47:48 | jaekwon: | you can solve the nothing at stake problem… put it at stake for short range forks. http://tendermint.com/posts/security-of-cryptocurrency-protocols/ |
03:48:01 | jaekwon: | you don't need to solve the long range fork problem. done. |
03:48:03 | rabbit2: | right |
03:48:16 | gmaxwell: | rabbit2: please don't come back until you've read pos.pdf and believe you can explain in your own terms what nothing at stake means in that context. :) |
03:48:22 | rabbit2: | this is just applying the same logic to long-range forks by making a special form of stake that is nontransferable |
03:48:29 | rabbit2: | anyways, really have to go |
03:48:39 | rabbit2: | I've read it already |
03:48:50 | rabbit2: | I understand what it means |
03:49:00 | rabbit2: | goodbye |
03:49:03 | gmaxwell: | Apparently not, because you believe that the expiration of a bond works. |
03:49:21 | kanzure: | hmm. |
03:49:47 | kanzure: | where do these people come from? |
03:50:25 | gmaxwell: | kanzure: there are some pretty strong monetary incentives to believe in varrious schemes right now. |
03:51:08 | kanzure: | does that factor losing everything by choosing a bad implementation/idea? |
03:51:24 | gmaxwell: | no, because you can externalize those costs. |
03:51:44 | fenn: | according to gmaxwell's time preference for money, it doesn't matter (now) if it all comes crashing down (later) |
03:51:48 | gmaxwell: | (plus, also keep in mind, that thats a 'tail' risk, ... if not an unlikely one, at least something outside of the now) |
03:52:04 | gmaxwell: | fenn: yep. |
03:52:56 | fenn: | mumble mumble hyperbolic discounting cognitive bias |
03:53:10 | kanzure: | "proof-of-work 2, now even proofier" (use different greek symbols) |
03:53:32 | jaekwon: | with all due respect… I think the entire proof-of-work camp is on the same boat. |
03:53:41 | kanzure: | it's not a camp |
03:53:59 | kanzure: | or a boat for that matter |
03:54:16 | fenn: | what you guys don't have an ephemerisle camp |
03:54:20 | gmaxwell: | I mean, the world is full of people that do things which are effectively long-shots, with high risk of failure, even if they don't realize it or even know how to estimate the risks. (90% of startups fail pre series-b and yet droves of (mostly young) people continue to work at them for long hours at below market pay) |
03:54:49 | kanzure: | right, it's certainly true that people make bad decisions |
03:55:07 | kanzure: | i think the plan should be to try not to encounter them as much as possible |
03:55:51 | andytoshi: | "X => we can assume the guy who did the work originally also controls the public key right now" if this is true then X is false by contrapositive |
03:57:08 | kanzure: | (and i don't mean tests or barriers to entry. i don't agree with those.) |
03:59:03 | andytoshi: | jaekwon: have you updaded the tendermint stuff to reflect that the security model is totally different from bitcoin's (and significantly weaker) |
03:59:07 | gmaxwell: | kanzure: some people from around here have gone off to create a private channel. I disagree with doing that, so I don't join it. |
03:59:16 | jaekwon: | andytoshi: it's not weaker, andytoshi. |
03:59:21 | andytoshi: | saying "you can solve the nothing at stake problem" is pretty misleading even if you follow it with "you don't need to solve the long range fork problem" |
03:59:35 | andytoshi: | sigh |
03:59:43 | jaekwon: | andytoshi: it's stronger. read this post. http://tendermint.com/posts/security-of-cryptocurrency-protocols/ |
04:00:01 | Luke-Jr: | gmaxwell: it's basically silent anyway |
04:00:17 | jaekwon: | and sigh all you want, i'm sorry there's a ton of cracks out here. |
04:00:21 | jaekwon: | *cranks. |
04:00:37 | jaekwon: | i'm sighing too. :/ |
04:00:54 | jaekwon: | and yes, the whitepaper has been updated. worth a new read. |
04:01:00 | gmaxwell: | kanzure: I've thought things could perhaps be a bit more productive if there were a test of a really low bar to get voice; so time saved on pure noise stuff could be spent on the less interesting things that still pass the bar... but I fear any cost is too high. People with valuable things to say don't need to prove anything to anyone... |
04:01:04 | jaekwon: | it's much clearer, is the feedback i've got. |
04:01:55 | gmaxwell: | Luke-Jr: it's quieter in here in the past because some of us have stopped participating in here partially from frustration. (myself included at times) |
04:01:55 | jaekwon: | gmaxwell: here's a test…. have you implemented your protocol from scratch? |
04:01:55 | jaekwon: | to completion? because you learn what's wrong with your algo as you implement it, usually. |
04:01:56 | jaekwon: | and if you haven't, then you can be sure that you've missed errors. |
04:02:18 | kanzure: | gmaxwell: yeah i strongly discourage the use of tests for that. i can see why you have thought of it, and i don't have an alternative yet, but i'm still cooking up some ideas... |
04:02:42 | Taek: | you never know, the things you've been saying to rabbit2 might get through, 3 years from now he could be a valuable contributor |
04:03:07 | Luke-Jr: | gmaxwell: well, if it's going to reduce the signal in the channel, I'd rather we just get stricter about the noise |
04:03:09 | andytoshi: | Taek: the problem is that none of us have the time to be professors |
04:03:25 | kanzure: | Luke-Jr: yeah maybe it would help to just ban quickly and indiscriminately |
04:03:32 | kanzure: | or at least +q |
04:03:37 | gmaxwell: | kanzure: e.g. a test can be created with a bar so low that basically only cohearence and simple background is required. But yes, things like that would have a non-trivial probablity of excluding e.g. me, just do to time constraints... so :( |
04:03:45 | andytoshi: | it's a bit unfair, because years ago we were able to ask really basic questions (because nobody knew the answers back then), and now we're getting annoyed at new people for doing the same thing |
04:03:54 | kanzure: | well, there's irc logs to read |
04:04:01 | kanzure: | those sorts of documents did not exist back then |
04:04:12 | Taek: | logs are difficult to parse, especially if you're not familiar with tools like grep |
04:04:16 | nubbins`: | if there's one thing noobs hate doing, it's reading logs |
04:04:20 | kanzure: | and some of this is just obvious if you think about it long enough |
04:04:29 | andytoshi: | sure, but it's hard to read logs because you can't step in to ask stuff, you're missing context, you don't know people, the timing and cadence are off, etc |
04:04:29 | kanzure: | and it is wrong to demand that people teach you the correct modes of thought over irc |
04:04:34 | Taek: | but things like asic.pdf and pos.pdf are a huge benefit to everyone |
04:04:35 | kanzure: | thought-transfer just doesn't work very well that way |
04:04:43 | Luke-Jr: | gmaxwell: well, if we +q people who say stupid things, then people with time constraints aren't affected |
04:04:45 | gmaxwell: | kanzure: some people in here have been opposed to that in the past. (in particular, amiller took issue with me punting some stuff I considered kooky). He expressed the view that he thought this channel should be a safe space to express ideas. And I can agree with that, it's really only the repetition that drives me nuts. |
04:04:53 | kanzure: | you are not going to learn how to emulate the bitcoin network in your head by reading two or three lines of irc messages |
04:05:03 | Luke-Jr: | andytoshi: I don't get annoyed with basic questions in #bitcoin |
04:05:24 | gmaxwell: | but it's often not the indivigual person's direct fault, e.g. that their the 101th person with the same proposal. |
04:05:34 | kanzure: | it is their fault for not checking |
04:05:38 | kanzure: | or asking |
04:05:40 | andytoshi: | Luke-Jr: this is true. maybe there should be a -wizards-help channel or something for people who are trying to understand nothing-at-stake |
04:05:43 | kanzure: | if they posed it as a question, i would be less hateful |
04:05:47 | gmaxwell: | well increasingly so, now that andytoshi has written up some stuff. |
04:06:01 | Luke-Jr: | maybe we can have a bot that makes bookmarks |
04:06:07 | gmaxwell: | but there is a lot of writing that hasn't been done yet. |
04:06:10 | andytoshi: | kanzure is the archival bot :) |
04:06:10 | Luke-Jr: | eg !tag nothing-at-stake 30m ago |
04:06:16 | kanzure: | beep boop |
04:06:25 | andytoshi: | Luke-Jr: that's a neat idea |
04:06:29 | kanzure: | i am quickly climbing back to my previous ~50,000 bookmarks |
04:06:29 | Luke-Jr: | then have a list of "bookmarks" we can link to |
04:06:30 | gmaxwell: | uh.. so there also seems to be some amount of information that exists only in some kind of special secret shared form. |
04:06:39 | kanzure: | https://github.com/davidlazar/jotmuch |
04:06:47 | kanzure: | oh there's a secret forum? |
04:06:53 | kanzure: | someone should dump that |
04:07:06 | gmaxwell: | In that I've noticed that long timers around here have certian understandings which are very clearly held and identically structured, and yet they've _never_ been explicitly discussed. |
04:07:14 | fenn: | he means implicit knowledge |
04:07:24 | kanzure: | well good ideas tend to gain momentum or something |
04:07:29 | kanzure: | you can't build castles on top of crap |
04:07:42 | kanzure: | well, you can try... |
04:08:03 | kanzure: | Luke-Jr: i think that's a good idea |
04:08:21 | gmaxwell: | Yes, implicit knoweldge. It's just a product of to understand X you must also understand Y thats it's based on... and in talking about X we'll manage to teach everyone Y without ever mentioning it. |
04:08:23 | Luke-Jr: | kanzure: up your alley to implement? :> |
04:08:37 | gmaxwell: | Which actually makes citing things from common understanding hard. |
04:08:47 | kanzure: | Luke-Jr: i'd rather just pay someone to implement it, i have better things to be pretending to do |
04:08:57 | Taek: | repetition really helps. The 12th time you explain nothing-at-stake to someone, you can still manage to get an increased understanding of how it's broken |
04:09:41 | kanzure: | gmaxwell: it seems that the most useful types of people are those that have lots of experience doing implicit-intuitive-mental-calculus already |
04:10:02 | kanzure: | or at least the ones that are least damaging to signal/noise |
04:10:18 | kanzure: | actually i don't know if it's experience |
04:10:37 | gmaxwell: | (I have this expirence when I meet with bitcoiners sometimes where I explain my perspective on things and get a bunch of "yes, yes, exactly that!", and I think some of this is where there is latent understanding, a kind of zen-of-bitcoin-technology and all I'm doing is plucking on it. ... but a lot of this stuff is not well documented.) |
04:11:13 | gmaxwell: | since we can have these nice conversations where all that is implicit and so we never disclose it where newcomers can easily absorb it. :( |
04:11:29 | kanzure: | zen-of-byzantine-agreement-and-problems-of-distributed-systems |
04:12:36 | fenn: | so nobody answered my question earlier: does it make sense to set up a "bitcoin university" with teachers, peer review, research programs |
04:12:44 | andytoshi: | fenn: who would teach? |
04:12:46 | kanzure: | no, because there would be no teachers |
04:12:55 | gmaxwell: | you all type too fast. |
04:13:03 | kanzure: | http://www.seanwrona.com/typeracer/profile.php?username=kanzure |
04:13:07 | andytoshi: | kanzure is wrecking the average |
04:13:13 | andytoshi: | the rest of us are 15 wpm |
04:13:38 | gmaxwell: | fenn: well worse, I don't think we yet know how to teach this subject. (not that we really know how to teach anything all that well...) |
04:13:39 | amiller: | wow kanzure you are faster than me http://www.seanwrona.com/typeracer/profile.php?username=socrates |
04:13:40 | kanzure: | i cracked a keyboard the other day, true story |
04:14:07 | Taek: | the old 4chan mantra of "lurk m0ar" comes to mind. just idling in the channel is hugely beneficial. |
04:14:23 | Luke-Jr: | fenn: where are you going to get the teachers? |
04:14:26 | kanzure: | ah, so we should implement 4chan-style harassment |
04:14:38 | Luke-Jr: | fenn: the problem is bootstrapping newbies IMO |
04:14:43 | fenn: | tbh i have no idea what most of you do all day |
04:14:53 | Luke-Jr: | ok, I'm being redundant *catches up* |
04:15:00 | kanzure: | mostly i complain over irc |
04:15:06 | kanzure: | (and write code) |
04:15:20 | fenn: | so "nobody has time to teach" doesn't really make sense, because obviously you're wasting time dealing with random people like rabbit2 |
04:15:21 | kanzure: | i also send out lots of email, that too... |
04:15:28 | kanzure: | well, isn't that teaching, fenn?? |
04:15:29 | gmaxwell: | Taek: I believe before I'd made any comment in bitcoin tech stuff I'd lurked several months, and also read the complete source code, mined a block (well ... not so easy anymore), and started making software changes locally. |
04:15:33 | kanzure: | oops only one "?" was intended |
04:15:38 | Luke-Jr: | fenn: I spend basically the whole day coding, to the near-neglect of my family :/ |
04:15:54 | kanzure: | gmaxwell: having people read the bitcoin source code might be interesting.... |
04:16:01 | andytoshi: | fenn: i read things far about 14 hours each day most days. i can have a convo like this because it requires no brain cycles |
04:16:05 | kanzure: | that's how all of the original knowledge was derived anyway |
04:16:10 | kanzure: | so it seems only natural to ask others to do the same |
04:16:28 | Luke-Jr: | the *complete* source code might be a bit much, but generally yes |
04:16:41 | gmaxwell: | it's somewhat larger than it was originally. ... Though hopefully we'll improve readability more in upcoming refactorings. |
04:16:50 | gmaxwell: | well you can skip qt/ for example. |
04:17:05 | Luke-Jr: | "find a consensus error in an alt implementation before you speak" |
04:17:09 | Luke-Jr: | :P |
04:17:19 | gmaxwell: | Luke-Jr: I'd love to say that, except eventually you run out. |
04:17:20 | kanzure: | today i found myself tracing SyncTransaction because i hadn't read it before :( |
04:17:33 | Luke-Jr: | gmaxwell: nah, the smart people will just do an alt impl themselves to find an error in |
04:17:35 | Luke-Jr: | :P |
04:17:48 | Taek: | gmaxwell: that's probably an order of magnatude more than the average person. Idk how you'd build that culture though without shutting people out. +q doesn't seem like an awful idea though |
04:17:59 | kanzure: | +q is pretty rude, heh |
04:18:26 | gmaxwell: | After matt did bitcoinj full node and found a dozen known-to-no-human behaviors I really wanted to say "any altimp that hasn't found at least one of those is worthless" ... but sadly eventually there are none left and the bar is unfair and you never know if thats where you are. |
04:18:40 | Luke-Jr: | kanzure: well, we don't want to stop them from learning |
04:18:43 | gmaxwell: | I normally _hate_ +q. Generally I'd rather ban people. |
04:18:46 | kanzure: | yes, asking for original bugs is bad |
04:19:05 | gmaxwell: | kanzure: not just bugs but "oh... this is probably surprising to everyone" |
04:19:30 | gmaxwell: | "hey guys, did you know X did Y?!" turns out that there are a lot of surprising things in bitcoin, only some of which you could call bugs. |
04:19:36 | kanzure: | also, i would emphasize to pow-haters that right now it is vastly more beneficial to read source code than any number of white papers |
04:20:00 | Taek: | gmaxwell: can you explain that more? I think I'd rather be +q'd than banned, though I'd probably feel pretty miserable about either |
04:20:09 | Luke-Jr: | like OP_SIZE ;) |
04:20:23 | Luke-Jr: | Taek: agreed fwiw |
04:20:45 | kanzure: | +q is often not represented in irc clients and you don't really know that you're on global ignore or w/e |
04:20:59 | gmaxwell: | In bitcoin-dev I +q almost univerally because I think there are transparency considerations. But generally if someone is behaving you want to keep them equal and respected as members of your community, and if they're not able to behave... you don't want them simmering and hating you, you want them to _leave_ and move on with their lives.. and +q is not good for achieving that. |
04:21:37 | Taek: | that's very fatherly lol |
04:22:17 | gmaxwell: | some people don't simmer and so +q would probably be fine, but a third party can't tell in advance. :) |
04:22:25 | kanzure: | i actually thought that rabbit2 was just one of the other users coming back with a different nick |
04:23:18 | gmaxwell: | kanzure: so ... yea, there have been people on IRC engaging in very elaborate trolling. I don't know that this knoweldge is actually useful. |
04:23:31 | kanzure: | thanks that's just going to make me more paranoid |
04:23:51 | kanzure: | there was this one person who genuinely thought that i had enough knowledge of cryonics to revive his mother from the dead (well, from cryonic storage) |
04:23:54 | kanzure: | (on irc) |
04:24:02 | gmaxwell: | E.g. for a long time there was a many nicked regular in #bitcoin who would start the most complex technical arguments, and it was very clear that he was pasting lines from IRC into goggle and that rapidly converting whatever came out into an argument. |
04:24:52 | fenn: | is it time for realtime deanonymization algorithms? |
04:25:09 | kanzure: | right, drop a link to a site with a js tracking library i guess |
04:25:26 | fenn: | just ngram frequency analysis |
04:25:56 | gmaxwell: | I only know this for sure because he was really good at driving me nuts, because the arguments would start off pretty sane and then it would become clear that he didn't know what the #@#$ he was talking about... eventually I got the hypothesis he was basically performing some kind of search madlibs and I gave him some techno jibberish only to get a response clearly constructed from the google result for it. |
04:27:22 | fenn: | was it xmj |
04:27:25 | gmaxwell: | realizing that this guy (in his multitude of identities) was one person was a material improvement to my mental well being (e.g. after that I went back through the logs and picked up the common subnet and common quit messages, and felt much saner). I don't think knowing that he was doing some kind of crazy google madlibs actually improved anything for me. |
04:27:55 | fenn: | oops i mean mosasaur |
04:28:12 | gmaxwell: | For as willing as I am to argue with folks online, ... I don't actually enjoy doing it much. |
04:28:43 | kanzure: | hmm. there has to be a better way to do this. |
04:29:30 | kanzure: | so i suppose it could just be "try to figure out teaching" but i don't think that's a good use of time here.... |
04:30:10 | gmaxwell: | kanzure: well step 1 is andytoshi's whitepapers... we could be doing more of that. |
04:30:12 | fenn: | sometimes "read the source" is misinterpreted as "go away" instead of its literal denotation |
04:30:20 | kanzure: | almost everyone in here is more valuable providing scarce programming than the immediate benefits of poor attempts at educating others |
04:31:12 | gmaxwell: | kanzure: well not exclusive. most people cannot be coding all the time. the level of engagement required here is usually pretty low. |
04:31:32 | kanzure: | personally my rule is "always be coding", but i sometimes stop coding by accident |
04:32:17 | kanzure: | (planning and thinking counts as coding) |
04:32:42 | gmaxwell: | hm. this is probably a good policy. |
04:32:47 | fenn: | "tacit knowledge refers to a knowledge possessed only by an individual and difficult to communicate to others via words and symbols. Therefore, an individual can acquire tacit knowledge without language. Apprentices, for example, work with their mentors and learn craftsmanship not through language but by observation, imitation, and practice." |
04:32:52 | GnarSith: | GnarSith has left #bitcoin-wizards |
04:33:18 | fenn: | seems inefficient but i don't have any better ideas |
04:33:24 | kanzure: | well there's certainly a craftsmanship aspect to coding |
04:34:17 | gmaxwell: | fenn: I've expressed the notion before that communicating a complex idea is like building a ship in a bottle. You want to build this complex edifice in the mind of another person, but you've got to stuff everything through a little cylinder with tongs. |
04:34:58 | Taek: | fenn: I don't think it's inefficient at all. Having your code reviewed by someone much better than you teaches you things that would take ages to figure out on your own, even with books and such |
04:35:17 | kanzure: | that's inefficient for the code reviewer |
04:35:17 | gmaxwell: | so good education is an engineering challenge of breaking the complex idea down into parts that fit through the channel and yet snap themselves togeather once they get to the other side. |
04:35:25 | fenn: | Taek: sure, for the student it's great, but the teacher has to do that N times |
04:35:34 | gmaxwell: | kanzure: review generally scales better than coding however. |
04:35:49 | kanzure: | seems to be breaking on irc :) |
04:36:00 | Taek: | log(n) if the students help each other out |
04:36:12 | kanzure: | hmm |
04:36:18 | Taek: | (log(n) might be too optimistic, but a lot less than n) |
04:36:45 | Luke-Jr: | it's somewhat efficient to code, read a page of IRC, respond, code |
04:36:50 | Luke-Jr: | drives some people nuts though |
04:37:16 | gmaxwell: | kanzure: there is a school of thought in some large development orgs. that your most expirenced coders should be spending most of their time reviewing the code of less expirenced folks. That basically most coding is time-fill boring stuff, and expirenced reviewers can rapidly cut through that, multiplying their effectiveness. I've seen enough of it that I think the idea has merit. |
04:37:20 | kanzure: | works for me. although i'm the multi-tasking 500-tabs-open watching-movies hacking-on-twenty-git-repos type of programmer. |
04:38:37 | fenn: | there's another school of thought that says if most of your coding is boilerplate boring stuff you should be using a more powerful language |
04:39:14 | kanzure: | gmaxwell: on a related note, i have been thinking about how to allocate attention/resources on large projects and stumbled into this: "So there's this well-known thing in quality engineering where getting bugs out earlier is easier, and this other well-known thing in programming where doing projects beginning-to-end gives you foresight about kinds of problems that might happen and makes the earlier designs bug-free and more efficient and ... |
04:39:20 | kanzure: | ... such. The right way to think about how projects get completed is as a dependency graph. A useful heuristic here is "How would I prove this is impossible as quickly as possible?". You want to prove the total task will work even if the subtasks fail, and otherwise abandon it. Then you want to prove each subtask is impossible, and replace it appropriately and re-plan integration as quickly as possible (etc etc). It's not as big a deal to ... |
04:39:26 | kanzure: | ... structure things perfectly if you have infinite resources and can parallelize everything, which is how the space shuttle and particle colliders are built. The big danger is doing the non-failfast steps first with one person. If one component has a major problem, that means one node is unexpectedly big. In practice, people replace that component with another component rather than delay, or engineer around it, or just accept the delay. ... |
04:39:32 | kanzure: | ... But the overall delay is not due to delay along a specific path--it's due to multiple delays, some on every critical path." |
04:39:35 | kanzure: | (actally i think that applies to all kinds of thought, not just engineering projects) |
04:39:38 | kanzure: | * kanzure polishes his keyboard |
04:40:24 | gmaxwell: | well that bumps into general "planning fallacy" there. |
04:40:52 | kanzure: | but there's evidence of things like entire particle colliders with millions of engineering components that don't get fully considered at the beginning and yet somehow still work at the end |
04:41:24 | kanzure: | (without reviewing every excruciating detail upfront) |
04:42:37 | gmaxwell: | well, if you look at biology there is never an overall architecture. Instead you have lots of parts which are responsive to their enviroment, and solve local problems. While on the overall level evolution achieves some global design, but at the nuts and bolts level almost all effects are local. So it's not surprising that the LHC works. |
04:42:56 | gmaxwell: | It's another question if things built that way can be efficient, most of biology certantly isn't. |
04:43:31 | kanzure: | there was some weak connection from that i was supposed to make regarding code review and imparting implicit knowledge |
04:44:03 | kanzure: | oh right, something about convining people to work from that general sort of plan of bounding their errors |
04:44:56 | kanzure: | or, at code review time, that appears as particularly defensive coding etc |
04:45:29 | kanzure: | .wik defensive programming |
04:45:30 | yoleaux: | "Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. The idea can be viewed as reducing or eliminating the prospect of Finagle's law having effect. Defensive programming techniques are used especially when a piece of software could be misused." — http://en.wikipedia.org/wiki/Defensive_programming |
04:45:38 | gmaxwell: | I attended a nice lecture by sussman once on building computer systems that were weakly coupled and worked more like biology that was interesting, maybe in 2007 or so? perhaps there is a copy of it online. |
04:46:34 | gmaxwell: | though I'm continually humbled at how hard a problm building robust systems actually is. |
04:46:41 | kanzure: | my favorite quote about biology is from jrayhawk, "... there is no source, the bytecode has multiple reentrent abstractions, is unstable and has a very low signal to noise ratio, the runtime is unbootstrappable, the execution is nondeterministic, it tries to randomly integrate and execute code from other computers... multiple reentrant and self-modifying abstractions. absolutely everything has subtle side effects." |
04:46:56 | kanzure: | (i spent time working in a molecular biology lab and then a plant physiology lab. also diybio stuff.) |
04:47:22 | fenn: | .title http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf |
04:47:23 | yoleaux: | fenn: Sorry, that doesn't appear to be an HTML page. |
04:47:45 | gmaxwell: | fenn: hot damn, thanks. |
04:48:31 | fenn: | i ran across that before, i forget how |
04:49:09 | fenn: | i also think http://langsec.org is relevant |
04:49:15 | gmaxwell: | fenn: I'm surprised I knew the year. Well I knew "pre-bitcoin". |
04:49:33 | gmaxwell: | in any case, the more time I spend on Bitcoin the further away I think we are from conquering these problems. Even basic directions are not obvious. |
04:51:07 | Taek: | conquering which problems? |
04:51:53 | gmaxwell: | building strongly robust systems. |
04:53:01 | gmaxwell: | For example, I was talking to sipa earlier about GMP in libsecp256k1. Someday we'd like to use the very fast libsecp256k1 in consensus critical code. At the moment libsecp256k1 depends on gmp though the only non-trivial thing it uses from libgmp is the modular inversion. The libgmp modular inversion is mystical number theory voodoo magic stuff, that does an inverse in sub-quadratic time, which seems impossible. It's much faster than ... |
04:53:07 | gmaxwell: | ... a normal fast implementation, I think maybe 10x faster than the one in openssl. Hundreds of times faster than a totally stupid implementation. For non-batch ecdsa verification that inverse is basically the largest thing in the profile. |
04:54:05 | gmaxwell: | Now, this mystery voodo inverse is a hurestic algorithim that automatically switches between several approaches. It is plausable that gmp contains bugs and there exist some numbers for which it computes incorrect inverses. In a simpler implementation it's more likely to be mostly wrong or all correct. |
04:55:22 | gmaxwell: | This is concerning for consensus critical usage, since if many nodes will miscompute the inverse of even a single number that you can find, you can construct a signature the uses that number, and fork the network. Moreover, GMP has several times replaced and retuned the algorithim (and probably will in the future), it also tunes it differently on different architectures. |
04:55:43 | fenn: | isn't it trivial to verify an inverse? |
04:55:53 | gmaxwell: | fenn: not when you care about speed. |
04:56:34 | gmaxwell: | I mean the whole goal is fast verification, going and multiplying out to check the inverse ... well switching to a simpler implementation is also an option. |
04:57:33 | kanzure: | yes, well, good luck comparing 1000 different implementation choices in an n-dimensional problem space. maybe make nsh do it, he's good at weird things like that. |
04:58:02 | gmaxwell: | One though I had was ... well, at initilization one could compute blinding constants, and it's very cheap to randomize the inverses. Actually the whole verification path can be pretty cheaply randomized. And so if there were a numerical problem, instead of a large cluster failing the same... some random fraction of hosts would fork off. .... Would this be an improvement? It's not clear at all. |
04:58:11 | kanzure: | (where has he been, anyway? did they finally arrest him?) |
04:59:25 | fenn: | idle 8 hours |
04:59:27 | kanzure: | ( http://mashable.com/2014/02/27/federal-reserve-hack/ ) |
04:59:33 | gmaxwell: | kanzure: nothing recent in google news for lauri love. |
04:59:46 | kanzure: | good. i can rest tonight. |
05:00:30 | gmaxwell: | So in this case here I have some idea thats reasonably cheap, and maybe gives the system more biological-like robustness. ... and it's not at all clear if its a horrible idea or a great one. |
05:01:18 | gmaxwell: | I think what sipa prefers is to not randomize it, and internalize the inverse (I prefer to do that too), and then get everyone on exactly the same code. |
05:02:09 | Taek: | say you randomize it, and then have each node do 2-3 computations. If there are any disagreements the node realizes it needs to run a lot more code and figure out what's going on |
05:02:16 | gmaxwell: | pratically that latter goal seems unreachable because it has a prerequsite that people understand the difficulties of consensus critical code in the same way that he or I do. |
05:02:33 | roidster: | roidster is now known as Guest38539 |
05:02:39 | gmaxwell: | Taek: but then again do 2-3 computations is at odds with performance. |
05:02:54 | Taek: | how much faster is libsecp256k1? |
05:03:12 | gmaxwell: | more than 6x faster than openssl. |
05:03:28 | Taek: | so even @ 3 computations, you've still got a huge speedup |
05:04:00 | gmaxwell: | there is a straight up trade-off between decenteralization and scale. So every bit of performance we get improves one or both of those. |
05:04:37 | gmaxwell: | If we weren't in a situation where the full node code is falling, I might buy that we have obvious breathing room and could give up a factor of N for a speculative robustness increase. |
05:06:56 | Taek: | thinking about biological systems... it's interesting to imagine a global consensus system that can tolerate some threshold of imprecision |
05:07:03 | gmaxwell: | libsecp256k1 is currently still somewhat better than half the speed of the ed25519 verifier, though it's all hand written simd assembly and secp256k1 is straight C (well, there is non-simd asm for the filed ops on x86_64 but its only about 3% faster than the current straight C code), plus ed25519 is schnorr, which is cheaper to verify (doesn't need that annoying inverse)... In theory I expect an equally optimized secp256k1 to be faster. |
05:07:33 | gmaxwell: | Taek: well consensus does tolerate some imprecision. ... uh. e.g. your own host can be faulty and everything (except you) keeps ticking. |
05:08:46 | gmaxwell: | There are a couple of places where blinding approaches can be applied which _may_ turn some synchronized failures into randomized ones. But it's unclear how much that can actually work. I've suggested several ideas now in this space, but I think none of them would have solved an actual problem that we've encountered in the past. |
05:09:27 | gmaxwell: | unfortunately it seems really hard to do if you're unwilling to take an interger factor slowdown. |
05:09:46 | Taek: | I wonder if we could do better though (not that I have suggestions). Imagine that *every* host is faulty by some epsilon (but randomly so) and yet the whole network manages to tick forward with stability |
05:10:14 | kanzure: | "assume that every host is malicious" |
05:11:10 | gmaxwell: | Taek: I have an intutive impression that there is likely a tradeoff between accepting honest-faulty and tolerating malicious hosts. |
05:11:29 | kanzure: | if malicious hosts are acceptable then are they really malicious? |
05:11:29 | gmaxwell: | Like the more tolerance you have the exponentially less secure to malice you become, but I'm waving my hands here. |
05:11:30 | kanzure: | etc |
05:12:13 | gmaxwell: | without a formal statement of what we're computing in the first place, the whole concept of faulty is a bit circular. |
06:13:29 | go1111111: | on the topic of what to do about repetitive questions from uneducated people in this channel: it would be really unfortunate if this made you the legitimate wizards retreat to some private channel, or type less in here |
06:13:41 | go1111111: | as someone trying to learn, i find these logs super valuable |
06:20:53 | go1111111: | my suggestion for preserving the sanity of wizards, and the "wizards talking to each other" vibe: write up some doc on #bitcoin-wizards etiquette. remind people of the doc if they are wasting your time, and be liberal with bans that expire in a day or two. back to lurking.. |
06:22:31 | jaekwon: | I'll be more than happy to moderate a subforum on proof-of-stake and related algorithms and tear the proposal apart. It's what I do now anyways. |
06:23:12 | jaekwon: | *by subforum i mean irc channel. could be #tendermint or something else |
06:32:31 | jaekwon: | You can point them my way and I'll be sure they don't come back here until they've been re-educated. Just point them to #tendermint. :) |
06:44:18 | Taek: | gmaxwell, you could probably do a lot better than run every signature 3 ways. If we know that ~99/100 are going to verify correctly, and we SPV-style assume that the longest chain is also accurate, you only verify something multiple times if it unexpectedly fails. |
06:44:44 | Taek: | the only risk then is verifying something that you shouldn't verify |
06:45:22 | Taek: | but if you apply some randomness to each of the verifications, an attacker has little to no ability to intentionally mess you up |
06:45:31 | Taek: | plus everyone else is going to reject the fork and pick something else |
06:47:12 | Taek: | :< but say an attacker releases a block with 10,000 verifications, knowing that nodes mess up 1% of the time. The majority of nodes will accept some bad transactions and consensus will break =/ |
06:48:50 | Taek: | oh wait no that's not a problem, because they'll reject the other 9000 bad transactions, and the block as a whole will be rejected |
07:05:39 | lclc_bnc: | lclc_bnc is now known as lclc |
07:30:18 | moribund112: | moribund112 is now known as moribund112[away |
07:42:09 | moribund112[away: | moribund112[away is now known as moribund112 |
08:09:04 | moribund112: | moribund112 is now known as moribund112[away |
08:41:45 | lclc: | lclc is now known as lclc_bnc |
08:43:18 | lclc_bnc: | lclc_bnc is now known as lclc |
09:05:18 | verne.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
09:05:18 | verne.freenode.net: | Users on #bitcoin-wizards: andy-logbot orik op_null cbeams AaronvanW askmike bitbumper moribund112[away fanquake mortale go1111111 Grishnakh NewLiberty woah TheSeven todaystomorrow copumpkin rusty nubbins` c0rw|sle_ zooko Dr-G3 coinheavy PRab Hunger- AdrianG waxwing jaekwon epscy nuke1989 altoz jgarzik iddo dansmith_btc luny prodatalab xmk3 coiner rasengan Cory Emcy jaekwon_ yoleaux ebfull LarsLarsen xabbix Starduster_ Baz___ heath samson_ bosma gwillen roconnor |
09:05:18 | verne.freenode.net: | Users on #bitcoin-wizards: rfreeman_w Greed adlai JohanTitor mkarrer__ livegnik sneak prepost BananaLotus Graftec d4de cryptokeeper atgreen Myagui LaptopZZ Flyer33 diametric a5m0 SDCDev @ChanServ bitname btcdrak dansmith_btc2 digitalmagus PaulCapestany shesek snorkl burcin Shiftos coutts Qfwfq wizkid057 phantomcircuit kgk maaku arowser spinza Nightwolf HaltingState paperbot Dyaheon bbrittain iambernie NikolaiToryzin forrestv null_radix Luke-Jr nickler bobke_ warptangent |
09:05:19 | verne.freenode.net: | Users on #bitcoin-wizards: mr_burdell Logicwax zibbo Meeh kanzure tromp_ SomeoneWeird Krellan tromp__ poggy pi07r_ sipa comboy_ mmozeiko lnovy Taek optimator_ [\\\] Guest39111 Apocalyptic throughnothing Pan0ram1x petertodd crescendo CryptOprah cfields kumavis sl01_ Fistful_of_Coins gmaxwell kinlo ahmed_ BlueMatt doc321R K1773R so Anduck Alanius lclc [d__d] gnusha_ espes___ hguux_ btc_ jbenet michagogo BigBitz DoctorBTC SubCreative otoburb wumpus artifexd EasyAt starsoccer |
09:05:19 | verne.freenode.net: | Users on #bitcoin-wizards: HM hollandais fluffypony fenn jaromil helo Keefe Iriez Eliel jrayhawk huseby phedny MRL-Relay berndj midnightmagic nsh Muis coryfields mappum andytoshi BrainOverfl0w fds4345 gazab warren gavinandresen pigeons nanotube asoltys gribble Graet smooth amiller lechuga_ abc56889 harrow roasbeef ryan-c [Tristan] TD-Linux catcow danneu |
09:14:20 | op_null: | kanzure: there are some pretty strong monetary incentives to believe in varrious schemes right now. |
09:14:25 | op_null: | the amount of money being thrown into dubious altcoins makes it inevitable that people will attempt to come looking for assertion that various schemes will work, usually based on interpretations of hand waving and vague descriptions of deeply technical topics. the hashcoin "whitepaper" I was commenting on previously now has an extended version, somehow with even more jargon and nonsense than before, and there's an entire forum of people attempting |
09:14:56 | op_null: | .. to read deep reasoning into something that was written without it. |
10:59:39 | moribund112[away: | moribund112[away is now known as moribund112 |
11:00:11 | moribund112: | moribund112 is now known as moribund112[away |
11:54:52 | c0rw|sle_: | c0rw|sle_ is now known as c0rw1n |
13:23:46 | lclc: | lclc is now known as lclc_bnc |
13:30:10 | lclc_bnc: | lclc_bnc is now known as lclc |
14:46:19 | kanzure: | "sure, but it's hard to read logs because you can't step in to ask stuff" |
14:46:28 | kanzure: | i think asking stuff about prior logs is a sane and reasonable thing for people to be encouraged to do |
15:01:05 | kanzure: | generally, if people who have recently entered the channel would ask questions instead of demanding that everyone else is wrong, that would help improve my mood significantly. it should not be about picking fights. |
15:01:09 | kanzure: | as much as i like pos/alts.pdf/asic.pdf they may seem a little hostile in a few parts to those who might not even be aware of existing biases they may have been exposed to. to someone who is economically motivated to believe any given bad idea, tersely-written words telling them they are wrong could easily feel like reading schilling (economically motivated attacks against your beliefs or something). but of course, nobody should have to be ... |
15:01:15 | kanzure: | ... water down anything to avoid hurting feelings... |
15:01:29 | kanzure: | example, sentence 2 of pos.pdf says it's fundamentally flawed, and as true as that may be i think it would be more helpful (and less distracting to readers) to simply emphasize that it doesn't evade the same impossibility result that bitcoin does, for example... |
15:01:37 | kanzure: | andytoshi: did you put those up in a git repo somewhere? i see the sidechains paper repo on your github account, but not anything for asic.pdf/pos.pdf/alts.pdf etc.. |
15:16:53 | andytoshi: | kanzure: they are in personal git repos, i think all of them are at guessable urls under git://git.wpsoftware.net/bitcoin/ but i could be wrong |
15:16:59 | andytoshi: | nowhere public ... i guess i should github them |
15:18:04 | kanzure: | cool |
15:22:37 | c0rw1n: | c0rw1n is now known as c0rw|away |
17:12:41 | Taek: | I was thinking, perfect decentralization... If every human on earth had equal mining power, _coin might be subject to massive sways in popular opinion. |
17:13:13 | Taek: | cheap verification is good but cheap participation is not necessarily so |
17:15:47 | kanzure: | what are you defining "perfect decentralization" as |
17:16:02 | Taek: | in this case, every human on earth having equal mining power |
17:16:38 | Taek: | I'll extend that to also having equal voting power when it comes to making changes to bitcoin-core |
17:16:50 | kanzure: | great now you have to define voting power :) |
17:17:54 | Taek: | heh... when a change has been proposed, everyone has the ability to vote, 51% say yes ==> change implemented |
17:18:05 | Taek: | everyone can propose changes |
17:18:27 | kanzure: | okay... and what happens when someone has a fork and excludes your change? |
17:18:48 | Taek: | depends on what the people with mining power decide to do |
17:19:56 | Taek: | controvertial changes would probably fragment the network |
17:20:57 | lclc: | lclc is now known as lclc_bnc |
17:21:52 | Taek: | the more relevant point I'm getting to is that a higher barrier to entry for being a miner might not be a bad thing. |
17:22:04 | Taek: | *high - it's already pretty high |
17:23:15 | kanzure: | right now the way it works is that anyone can be a miner with a very low barrier to participation |
17:24:27 | Taek: | except you need specialized hardware, and a working knowledge of the mining market, the hashrate changes, and an understanding of electricity & hardware deprication costs |
17:24:49 | kanzure: | you don't need specialized hardware to attempt to mine |
17:25:10 | moribund112: | moribund112 is now known as moribund112[away |
17:25:36 | tromp_: | as long as you're happy with odds of making anything being lower than winning lottery |
17:25:59 | kanzure: | that's not about participation |
17:26:32 | Taek: | miners control softforks |
17:26:45 | Taek: | softforks are a form of participation |
17:28:57 | moribund112[away: | moribund112[away is now known as moribund112 |
17:29:11 | Eliel: | * Eliel wonders if it'd actually make a significant dent to the hashrate if everyone in the world set up one computer to CPU mine :P |
17:31:22 | kanzure: | let's be generous and say 500 MH/sec per cpu, assume 7 billion cpus, that might be about 1-2 exahashes? |
17:31:26 | Eliel: | assuming each of those mined at 5Mh/s, that'd make 25Ph/s ... ~10 of the network currently |
17:31:42 | Eliel: | 10% |
17:31:51 | kanzure: | wait why did i pick 500? |
17:32:51 | Eliel: | maybe you misread my cpu as gpu :P |
17:34:42 | moribund112: | moribund112 is now known as moribund112[away |
17:35:47 | Taek: | it'd be more of a dent if manufacturers started shipping computers with small asics... if there was demand for it, I'm sure someone would sell the product. |
17:37:20 | Eliel: | a bitcoin asic in every processor :P |
17:37:44 | Eliel: | would probably be pretty cheap |
17:37:56 | Eliel: | for a low powered one |
17:40:02 | helo: | Eliel: would be pretty unprofitable too :/ |
17:41:30 | SomeoneWeird: | SomeoneWeird is now known as Guest40205 |
17:43:03 | tromp_: | in germany, could&heat pays you to keep their cloudserver in your basement |
17:43:13 | tromp_: | so they save on cooling costs |
17:44:19 | tromp_: | still, that's only physical decentralization, which doesnt help:( |
17:44:52 | Eliel: | * Eliel wonders if there's a way to construct a PoW algo such that it's possible to combine lower difficulty results for the same data without O(n) verification. |
17:45:12 | tromp_: | where n is? |
17:45:24 | Eliel: | the number of lower difficulty results being combined |
17:46:19 | tromp_: | ah, like compressing the shares? |
17:46:25 | Eliel: | yes, pretty much |
17:46:58 | Eliel: | but the point is not to save space but rather keep the verification cost reasonable |
17:47:05 | Alanius: | I guess you could generate a snark saying something like "I have solved the PoW puzzle n times for difficulty 1/n" |
17:48:43 | tromp_: | that seems exceedingly unlikely to be possible |
17:48:48 | Alanius: | why? |
17:49:11 | tromp_: | sorry, was responding to Eliel:( |
17:49:33 | tromp_: | now that you mention snarks it seems less impossible:( |
17:50:04 | Eliel: | of course, you can probably just keep the best and get a good approximation :P |
17:50:08 | Eliel: | d'oh |
17:51:06 | Taek: | I realized, right now 7 billion cpus might add up to 10% hashrate, and 7 billion gpus might be 200% or whatever, but that's not a fair equation |
17:51:22 | Taek: | if Bitcoin had 7 billion regular users, the market cap would be several orders of magnitude higher |
18:38:57 | instagibbs: | helo: while unprofitable, people would lose such tiny amounts separately, and the aggregate security would be quite robust. 7B people spending a cent a day mining would give $70M in security a day. To me anything even close to this scenario is PoW's best chance long-term |
18:44:10 | helo: | 7B people -.- |
18:46:51 | instagibbs: | CPUs, whatever. Point being |
18:48:02 | instagibbs: | a large(how large? who knows) amount of people mining essentially altruistically for a small amount of money(?) would make PoW robust, or at least more robust than it is now |
18:48:19 | instagibbs: | #people x #cost = whatever security you want |
18:49:11 | instagibbs: | Maybe amiller has got it better and the -EV games mining can be figured out. But same result. |
18:49:31 | kanzure: | it is bad to assume altruism |
18:49:39 | instagibbs: | I assume nothing |
18:49:41 | kanzure: | because there are already working implementations that don't have to rely on altruism |
18:49:47 | instagibbs: | it's an observation that it's a possible result |
18:49:56 | instagibbs: | ? |
18:50:03 | kanzure: | and what is your measurement of robust anyway |
18:50:16 | instagibbs: | for me im thinking of reorgs from attackers |
18:50:25 | instagibbs: | but what do you mean "already working impl" |
18:51:10 | kanzure: | proof of work. |
18:51:48 | kanzure: | reorgs are not always malicious |
18:51:53 | instagibbs: | if people are mining not at a loss, barring damage to system reputation, reorgs are basically free |
18:52:00 | kanzure: | and there's no real way to discriminate between "legitimate" and "illegitimate" reorgs |
18:52:00 | instagibbs: | and that's fine, if they accidetnally reorg that's on them |
18:52:15 | instagibbs: | has really nothing to do with "good" or "bad" |
18:52:16 | helo: | i'd guess the ratio of altruistic (at a loss) miners to population would be closer to 1:100 or 1:1000 than 1:1, even if every desktop CPU had a mining chip in it |
18:52:49 | tromp_: | or if a cpu friendly pow was used |
18:52:51 | helo: | is there validation-only mining software that only keeps the utxo? |
18:53:09 | instagibbs: | im not even calling altruism "good" in this scenario. Just an observation of how expensive a deliberate attack would become. |
18:53:57 | instagibbs: | maybe a billion miners is a bad idea for reasons listed before with "voting" and mob mentality |
18:56:44 | instagibbs: | maybe the altruistic miners vote with their hashes to become gov coin :) |
18:57:02 | helo: | democracy is probably not too bad |
18:57:20 | helo: | better that than a mining dictatorship |
18:58:05 | instagibbs: | ASIC growing pains are tough |
18:58:38 | helo: | mining is tough... the competitiveness is just brutal |
18:58:58 | instagibbs: | I don't think I'm the only one who would mine at a small loss |
18:59:05 | instagibbs: | I'm just not willing to sink thousands into loss |
18:59:23 | instagibbs: | hence my theorizing about future. Just a dreamer |
18:59:29 | kanzure: | "gov coin" doesn't make senes |
18:59:40 | kanzure: | *sense |
18:59:56 | helo: | mining at a small loss probably means that your hardware is not only inefficient, but also very slow, compared to the majority of mining equiptment. so the actual security benefit would likely be pretty small. |
18:59:57 | instagibbs: | kanzure: you're really reading too much into what I'm saying. I'm just saying "altruism" means whatever the miner thinks is good |
19:01:34 | instagibbs: | they sacrifice something for the "greater good" |
19:01:39 | kanzure: | "the belief in or practice of disinterested and selfless concern for the well-being of others" |
19:01:54 | instagibbs: | yes, and that's different for different people |
19:01:55 | kanzure: | what a miner thinks is good is not at all necessarily related to being selfless, argh |
19:02:00 | kanzure: | if you redefine words it makes conversation impossible |
19:02:08 | instagibbs: | I'm sorry for being sloppy |
19:02:25 | helo: | it takes determined effort to be a significant mining contributor, even if you have large numbers of participants. |
19:02:30 | instagibbs: | an altruistic miner can think differently about what's good for others |
19:02:56 | instagibbs: | I could think for example, gov coin is a great idea. I'd be an idiot. Doesn't detract from my altruistic quotient. |
19:03:17 | kanzure: | so behaving non-altruistically counts as altruism? |
19:03:57 | instagibbs: | Your definition of what *actions* are required in altruism is different than others' |
19:04:05 | instagibbs: | I might think it's giving money to poor |
19:04:13 | instagibbs: | some might think euthenasia |
19:04:19 | instagibbs: | I'm not being facetious |
19:04:33 | kanzure: | so you just changed your mind? |
19:04:40 | kanzure: | a moment ago you were claiming "Doesn't detract from my altruistic quotient." |
19:05:02 | instagibbs: | Ok euthenasia example is great |
19:05:32 | instagibbs: | Some think cripples should be "put out of misery". Some don't. People, depending on their beliefs, may doing altruistic things to *either end* |
19:05:44 | instagibbs: | each side finds the other morally abhorrent |
19:06:13 | instagibbs: | Mining policy, hard forks, etc, are subjective. |
19:06:38 | instagibbs: | Ok don't want to pollute the channel too much. Said my part. |
19:07:36 | instagibbs: | have a good one kanzure |
19:13:22 | roidster: | roidster is now known as Guest61285 |
19:29:52 | Luke-Jr: | …. |
19:33:28 | go1111111: | is there some secret trick for searching for substrings in the #bitcoin-wizards logs (https://botbot.me/freenode/bitcoin-wizards/)? I'd like to be able to search for "zer" and have it match "zero" |
19:37:43 | instagibbs: | the search function on botbot seems to work for such purposes |
19:38:06 | instagibbs: | oh nevermind |
19:38:31 | instagibbs: | for some reason works only for your comment(i suppose because you wrote both "zer" and "zero" ends up highlighting both) |
19:39:24 | kanzure: | go1111111: use grep |
19:44:35 | go1111111: | kanzure: is there a way to download the full logs from that site that i'm not seeing? otherwise my grepping would be on incomplete data. it would be super useful to just be able to do this via the site. who maintains that page? maybe i can add the feature |
19:53:41 | c0rw|away: | c0rw|away is now known as c0rw1n |
20:00:05 | gwillen: | gwillen is now known as lordbyron |
20:00:23 | lordbyron: | lordbyron is now known as gwillen |
20:15:42 | andytoshi: | go1111111: there are (incomplete) logs at download.wpsoftware.net/bitcoin/wizards/ that are easy to scrape and grep through |
20:37:41 | kanzure: | go1111111: wget -m -np |
20:57:44 | roidster: | roidster is now known as Guest63987 |
22:06:41 | op_null: | with the comments earlier about 7B people each CPU mining is sort of insane from a heat and power standpoint. CPUs use a ridiculous amount of power per hash compared with an ASIC, it's very easy to forget that. |
22:06:51 | op_null: | "7B people spending a cent a day mining would give $70M in security a day. To me anything even close to this scenario is PoW's best chance long-term" |
22:07:18 | sipa: | what's the hash-per-watt factor between current cpu's and current asics? |
22:07:26 | op_null: | for me it's more like 60c a day, and my power costs are quite low compared with somewhere like Germany. |
22:08:17 | op_null: | I think for my best CPU it's around 20MH/s at 95W TDP, plus a few tens of watts in support hardware and cooling. |
22:10:41 | op_null: | the current best for an ASIC is something like 0.6GH (it all depends on the voltage you run them at), but KNCminer is claiming that their next batch (which they aren't selling to the public) will be around 0.05W/GH (assuming that's before the DC-DC, but still very impressive) |
22:25:40 | instagibbs: | op_null: herp, I meant ASICs put on commodity machines. Something that doesn't exist ofc |
22:27:21 | instagibbs: | assuming magical future where hash per watt is "stable" |
22:27:46 | op_null: | instagibbs: I get the idea, but there's reasonably low utility in the heat that an asic puts out. you really want to keep the chips as absolutely cool as possible, so other than room heating system I can't think what it could be used for. |
22:28:39 | op_null: | I suspect phase change heating is probably better for that task anyway. |
22:28:43 | instagibbs: | op_null: Agreed. That's why I'm calling it altruistic. Ofc you'd need people to donate. Pretty much a PoB |
22:30:34 | instagibbs: | i wonder if water heater ASICs screw up incentives, like "useful" PoW... hmm |
22:30:57 | op_null: | "useful" PoW is pretty messed up already. |
22:52:36 | fenn: | low temperature differential can be used for electricity generation, with diminishing efficiency as temperature drops |
22:54:00 | op_null: | hybrid Bitcoin miner / stirling engine? |
22:55:36 | fenn: | after seeing those photos of the mining farm on fire, probably better to worry about other engineering aspects first |